home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 5 / Apprentice-Release5.iso / Information / CSMP Digest / volume 3 / csmp-digest-v3-129 < prev    next >
Text File  |  1995-12-26  |  112KB  |  2,841 lines

  1. C.S.M.P. Digest             Tue, 26 Dec 95       Volume 3 : Issue 129
  2.  
  3. Today's Topics:
  4.  
  5.         Alt.Sources.Mac Archive
  6.         Apple Disk Copy Image Format Needed!
  7.         Apple Events to Eudora to send mail...
  8.         Block copy on 604 slow
  9.         Choosing a Help Authoring Tool
  10.         Events vs. GetKeys
  11.         How do I draw dashed lines?
  12.         Network code on a PPC native project?
  13.         Spheres in Q3D?
  14.         WaitNextEvent & Background Processing
  15.  
  16.  
  17.  
  18. The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
  19. (pottier@clipper.ens.fr).
  20.  
  21. The digest is a collection of article threads from the internet
  22. newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
  23. csmp.games. It is designed for people who read news semi-regularly and
  24. want an archive of the discussions.  If you don't know what a
  25. newsgroup is, you probably don't have access to it. Ask your systems
  26. administrator(s) for details. If you don't have access to news, you
  27. may still be able to post messages to the group by using a mail server
  28. like anon.penet.fi (mail help@anon.penet.fi for more information).
  29.  
  30. Each issue of the digest contains one or more sets of articles (called
  31. threads), with each set corresponding to a 'discussion' of a particular
  32. subject.  The articles are not edited; all articles included in this digest
  33. are in their original posted form (as received by our news server at
  34. nef.ens.fr).  Article threads are not added to the digest until the last
  35. article added to the thread is at least two weeks old (this is to ensure that
  36. the thread is dead before adding it to the digest).  Article threads that
  37. consist of only one message are generally not included in the digest.
  38.  
  39. The digest is officially distributed by two means, by email and ftp.
  40.  
  41. If you want to receive the digest by mail, send email to listserv@ens.fr
  42. with no subject and one of the following commands as body:
  43.     help                                Sends you a summary of commands
  44.     subscribe csmp-digest Your Name     Adds you to the mailing list
  45.     signoff csmp-digest                 Removes you from the list
  46. Once you have subscribed, you will automatically receive each new
  47. issue as it is created.
  48.  
  49. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
  50. Questions related to the ftp site should be directed to
  51. scott.silver@dartmouth.edu.
  52.  
  53. -------------------------------------------------------
  54.  
  55. >From dnebing@news.epix.net (David Nebinger)
  56. Subject: Alt.Sources.Mac Archive
  57. Date: 8 Dec 1995 23:01:46 GMT
  58. Organization: epix.net
  59.  
  60. The alt.sources.mac archive is up and active.  Currently only anon FTP
  61. access is supported; I plan to have WWW access ready to go by the end of
  62. next week.
  63.  
  64. Point your ftp tool to:
  65. <ftp://ftp.AmbrosiaSW.com/pub/alt.sources.mac/>
  66.  
  67. Point your www tool to:
  68. <http://www.AmbrosiaSW.com/alt.sources.mac/>
  69.  
  70. I have the archives filled with the files I received before 1/1/95; the
  71. files that I have collected this year will be appearing in the archive soon.
  72. The digest for the year will also be published soon.
  73.  
  74. Dave Nebinger
  75. <http://www.AmbrosiaSW.com/~dnebing/>
  76. <mailto:dnebing@AmbrosiaSW.com>
  77.  
  78. P.S. the IP address for Ambrosia is 206.27.96.210.
  79.  
  80.  
  81. >From dnebing@news.epix.net (David Nebinger)
  82. Subject: Alt.Sources.Mac Archive
  83. Date: 8 Dec 1995 23:01:08 GMT
  84. Organization: epix.net
  85.  
  86. The alt.sources.mac archive is up and active.  Currently only anon FTP
  87. access is supported; I plan to have WWW access ready to go by the end of
  88. next week.
  89.  
  90. Point your ftp tool to:
  91. <ftp://ftp.AmbrosiaSW.com/pub/alt.sources.mac/>
  92.  
  93. Point your www tool to:
  94. <http://www.AmbrosiaSW.com/alt.sources.mac/>
  95.  
  96. I have the archives filled with the files I received before 1/1/95; the
  97. files that I have collected this year will be appearing in the archive soon.
  98. The digest for the year will also be published soon.
  99.  
  100. Dave Nebinger
  101. <http://www.AmbrosiaSW.com/~dnebing/>
  102. <mailto:dnebing@AmbrosiaSW.com>
  103.  
  104. P.S. the IP address for Ambrosia is 206.27.96.210.
  105.  
  106.  
  107. >From dnebing@news.epix.net (David Nebinger)
  108. Subject: Alt.Sources.Mac Archive
  109. Date: 8 Dec 1995 22:59:55 GMT
  110. Organization: epix.net
  111.  
  112. The alt.sources.mac archive is up and active.  Currently only anon FTP
  113. access is supported; I plan to have WWW access ready to go by the end of
  114. next week.
  115.  
  116. Point your ftp tool to:
  117. <ftp://ftp.AmbrosiaSW.com/pub/alt.sources.mac/>
  118.  
  119. Point your www tool to:
  120. <http://www.AmbrosiaSW.com/alt.sources.mac/>
  121.  
  122. I have the archives filled with the files I received before 1/1/95; the
  123. files that I have collected this year will be appearing in the archive soon.
  124. The digest for the year will also be published soon.
  125.  
  126. Dave Nebinger
  127. <http://www.AmbrosiaSW.com/~dnebing/>
  128. <mailto:dnebing@AmbrosiaSW.com>
  129.  
  130. P.S. the IP address for Ambrosia is 206.27.96.210.
  131.  
  132.  
  133. ---------------------------
  134.  
  135. >From Programer <progrmer@tiac.net>
  136. Subject: Apple Disk Copy Image Format Needed!
  137. Date: Tue, 5 Dec 1995 13:14:10 -0500
  138. Organization: The Internet Access Company
  139.  
  140.  
  141. Does anyone know where i can find or can send me the format to Apple's 
  142. Disk Copy utilties....I have a need to read in those Image files and I 
  143. need to know how they are layed out compared to the real disk!
  144.  
  145. Thanks in advance!
  146.  
  147. Marek
  148. progrmer@tiac.net
  149. http://www.cs.brandeis.edu/~progrmer
  150.  
  151.  
  152.  
  153. +++++++++++++++++++++++++++
  154.  
  155. >From jonpugh@netcom.com (Jon Pugh)
  156. Date: Mon, 11 Dec 1995 01:16:08 GMT
  157. Organization: Apple Computer
  158.  
  159. In article <Pine.SUN.3.91.951205131345.544B-100000@sunspot.tiac.net>,
  160. Programer <progrmer@tiac.net> wrote:
  161.  
  162. > Does anyone know where i can find or can send me the format to Apple's 
  163. > Disk Copy utilties....I have a need to read in those Image files and I 
  164. > need to know how they are layed out compared to the real disk!
  165.  
  166. The MungeImage source contains this information.
  167.  
  168. <ftp://mirror.apple.com//mirrors/Info-Mac.Archive//dev/src/
  169.   munge-image-120-p.hqx>
  170.  
  171. Jon
  172.  
  173. ---------------------------
  174.  
  175. >From cwatson@cam.org (Sean McBride)
  176. Subject: Apple Events to Eudora to send mail...
  177. Date: Sun, 03 Dec 1995 16:48:56 -0500
  178. Organization: Communications Accessibles Montreal, Quebec Canada
  179.  
  180. I'm wondering if someone can point me in the right direction of
  181. information pertaining to sending apple events (to Eudora for example) to
  182. create a new piece of mail to sent to a person.
  183.  
  184. I've seen lots of programs do this, CyberFinder for example...
  185.  
  186. Thanks in advance!
  187.  
  188. _______________________________________________________________________
  189.   H H      |                   |                                      |
  190.   | |      | Sean McBride      |                                      |
  191. H-C-C-O-H  | cwatson@cam.org   |     If you drink, don't drive.       |
  192.   | |      | Montreal, Canada  |        Crawl home                    |
  193.   H H      |                   |     0010 1001 1010                   |
  194. - ---------------------------------------------------------------------
  195.  
  196. +++++++++++++++++++++++++++
  197.  
  198. >From sgruby@qualcomm.com (Scott Gruby)
  199. Date: Tue, 05 Dec 1995 17:20:26 -0800
  200. Organization: QUALCOMM, Inc.
  201.  
  202. In article <cwatson-0312951648570001@cwatson.hip.cam.org>, cwatson@cam.org
  203. (Sean McBride) wrote:
  204.  
  205. > I'm wondering if someone can point me in the right direction of
  206. > information pertaining to sending apple events (to Eudora for example) to
  207. > create a new piece of mail to sent to a person.
  208. > I've seen lots of programs do this, CyberFinder for example...
  209. > Thanks in advance!
  210.  
  211. You can find some example code at:
  212.  
  213. <ftp://ftp.qualcomm.com/quest/mac/eudora/scripts/c-samples.hqx>
  214.  
  215. (There are some minor mistakes with it, but it should lead you in the
  216. right direction.)
  217.  
  218. -- 
  219. Scott Gruby
  220. sgruby@qualcomm.com
  221.  
  222. +++++++++++++++++++++++++++
  223.  
  224. >From fairgate@vespucci.iquest.com (Fairgate Technologies)
  225. Date: 8 Dec 1995 22:49:09 -0600
  226. Organization: interQuest Online Services -- Huntsville, AL
  227.  
  228. cwatson@cam.org (Sean McBride) writes:
  229.  
  230. >I'm wondering if someone can point me in the right direction of
  231. >information pertaining to sending apple events (to Eudora for example) to
  232. >create a new piece of mail to sent to a person.
  233.  
  234. Check out
  235. ftp://ftp.qualcomm.com/quest/mac/eudora/scripts/new-message.hqx. It's
  236. a sample that should point you in the right direction. The sample code
  237. has some bugs but you'll find them fairly quickly :)
  238.  
  239. Cheers,
  240. -Paul
  241.  
  242. -- 
  243. Paul Robichaux          paul@fairgate.com               Fairgate Technologies
  244.        Fairgate Technologies does custom Mac & WWW development.
  245.                     <URL:http://www.fairgate.com>
  246.          <URL:http://www.fairgate.com/people/paul/index.html>
  247.  
  248. +++++++++++++++++++++++++++
  249.  
  250. >From rac@intrigue.com (Robert Coie)
  251. Date: Mon, 11 Dec 1995 11:56:31 -0800
  252. Organization: Intrigue Corporation
  253.  
  254. In article <cwatson-0312951648570001@cwatson.hip.cam.org>, cwatson@cam.org
  255. (Sean McBride) wrote:
  256.  
  257. : I'm wondering if someone can point me in the right direction of
  258. : information pertaining to sending apple events (to Eudora for example) to
  259. : create a new piece of mail to sent to a person.
  260. : I've seen lots of programs do this, CyberFinder for example...
  261. : Thanks in advance!
  262.  
  263. I believe the Aretha release has tools to do this
  264. <http://www.hotwired.com/staff/userland/aretha/>, and Qualcomm's FTP site
  265. has a document with info about the scripting interface to Eudora.
  266.  
  267. Robert Coie
  268. Implementor, Intrigue Corporation
  269. rac@intrigue.com
  270.  
  271. ---------------------------
  272.  
  273. >From steele@isi.edu (Craig S. Steele)
  274. Subject: Block copy on 604 slow
  275. Date: Tue,  5 Dec 1995 18:30:53 -0800
  276. Organization: USC Information Sciences Institute
  277.  
  278. I'm trying to benchmark block copy rates of various sizes for PowerPCs.  My 
  279. results are disappointing for the 604, and cause me to wonder what it is I 
  280. don't understand. Testing on a 9500/120, to which I have limited access, gives 
  281. the following results for copy code using 32-bit integer and 64-bit double 
  282. load and stores, respectively:
  283.  
  284. Asm lvector copy of  1024 doubles in  44.8 nS/acc,  5.4 clocks/acc,  85.1 MB/s
  285. Asm dvector copy of  1024 doubles in  34.1 nS/acc,  4.1 clocks/acc, 111.9 MB/s
  286.  
  287. The source array is aligned to 4K, the destination array to 4K+0x100, to avoid 
  288. possible aliasing interlocks.  The source array is preloaded immediately 
  289. before the copy routine is called, so I would expect everything to run at L1 
  290. cache rates.
  291.  
  292. I would naively expect the copy code to average about 1.5 clocks per load or 
  293. store.  Instead, my code reports over 4 clocks/access.  The code uses the 
  294. time-base register for timing, which shouldn't cause significant cache 
  295. disturbance.
  296.  
  297. Can anyone contradict, corroborate, or explain my poor results? If I can't do 
  298. better than this, we'll have to build extra hardware :-(
  299. Thanks in advance.
  300. -Craig
  301.  
  302.         exportf2        dvec_copy
  303.         mtctr   r5              ; init loop counter
  304.         addi    r3,r3,-8        ; predecrement pointer by double size
  305.         addi    r4,r4,-8        ; predecrement pointer by double size
  306.         li      r6,8            ; cache line alignment constant for dcbz
  307.         b       dvc_1
  308.         align   6
  309. dvc_1
  310.         dcbz    r6,r3           ; kill dest. cache line
  311.         lfd     fp0,8(r4)
  312.         lfd     fp1,16(r4)
  313.         lfd     fp2,24(r4)
  314.         lfdu    fp3,32(r4)
  315.         stfd    fp0,8(r3)
  316.         stfd    fp1,16(r3)
  317.         stfd    fp2,24(r3)
  318.         stfdu   fp3,32(r3)
  319.         bdnz    dvc_1           ; test loop condition
  320.         blr
  321.  
  322.  
  323.  
  324. Craig S. Steele - Not yet Institutionalized
  325.  
  326.  
  327.  
  328. +++++++++++++++++++++++++++
  329.  
  330. >From rbarris@netcom.com (Robert Barris)
  331. Date: Wed, 6 Dec 1995 09:46:47 GMT
  332. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  333.  
  334. In article <9512051830.AA53505@kandor.isi.edu>,
  335. Craig S. Steele <steele@isi.edu> wrote:
  336. >I'm trying to benchmark block copy rates of various sizes for PowerPCs.  My 
  337. >results are disappointing for the 604, and cause me to wonder what it is I 
  338. >don't understand. Testing on a 9500/120, to which I have limited access, gives 
  339. >the following results for copy code using 32-bit integer and 64-bit double 
  340. >load and stores, respectively:
  341. >
  342. >Asm lvector copy of  1024 doubles in  44.8 nS/acc,  5.4 clocks/acc,  85.1 MB/s
  343. >Asm dvector copy of  1024 doubles in  34.1 nS/acc,  4.1 clocks/acc, 111.9 MB/s
  344.  
  345. OK, in regular "bytes", you appear to be moving (for examples sake)
  346.  8192 bytes
  347.  from address (say) 0x1000000
  348.  to  address (say)  0x1002100.
  349.  
  350. So you are reading 8K and writing 8K as I read it... in a perfect world 
  351. all of your data would fit (precisely) into the L1 d cache.
  352.  
  353. >The source array is aligned to 4K, the destination array to 4K+0x100, to avoid 
  354. >possible aliasing interlocks.  The source array is preloaded immediately 
  355. >before the copy routine is called, so I would expect everything to run at L1 
  356. >cache rates.
  357.  
  358. Except that you are sharing that L1 with things like interrupt tasks, 68K
  359. interrupt tasks (which invoke the emulator causing additional pollution),
  360. and so on.
  361.  
  362. Since as far as I know, there is no way to completely shut off PowerPC
  363. interrupts, quantifying the effect of background processes on your cache 
  364. population can be a bit tricky.
  365.  
  366. >I would naively expect the copy code to average about 1.5 clocks per load or 
  367. >store.  Instead, my code reports over 4 clocks/access.  The code uses the 
  368. >time-base register for timing, which shouldn't cause significant cache 
  369. >disturbance.
  370.  
  371. When you say per access, do you mean per double "moved" as in a read and 
  372. a write, or per double accessed, as in the read or the write alone?
  373.  
  374. I guess I can work it out: 110MB/s (say it's 120 for arguments sake) is 
  375. about 1MB per million clocks (at 120MHz). Or about a byte moved per clock, or
  376. a double moved per 8 clocks. OK so that's 4 per double read, 4 per 
  377. double write (on average).
  378.  
  379. Suggestions:
  380.  1. Plot speed versus vector length. Look for nonlinearities.
  381.    (deliberately shrink or grow the vector).
  382.  
  383.  2. wiggle that 256 byte offset factor some more. or make it zero.
  384.     I do not think the 4-wayness would become a problem until you went
  385.     above 8K vectors, then very little would help...
  386.  
  387.  3. think about cache hinting at or near the bottom of the loop.
  388.     if for some reason a cache line which you are going to read from
  389.     has been dropped, it's good to schedule its re-fetch as far ahead as 
  390.     possible. I'm sure Tim Olson can elaborate much more better good :)
  391.  
  392.  4. I hear Exponential Technology has a faster BiCMOS 604 coming...
  393.  
  394. Rob Barris
  395. Quicksilver Software Inc.
  396. rbarris@quicksilver.com
  397. * opinions expressed not necessarily those of my employer *
  398.  
  399. +++++++++++++++++++++++++++
  400.  
  401. >From steele@isi.edu (Craig S. Steele)
  402. Date: Wed,  6 Dec 1995 12:41:15 -0800
  403. Organization: USC Information Sciences Institute
  404.  
  405. In article <rbarrisDJ5sHz.MJy@netcom.com>, rbarris@netcom.com (Robert Barris) 
  406. writes:
  407. > In article <9512051830.AA53505@kandor.isi.edu>, Craig S. Steele 
  408. > <steele@isi.edu> wrote: 
  409. > >I'm trying to benchmark block copy rates of various sizes for 
  410. > >PowerPCs.  My results are disappointing for the 604, and cause me 
  411. > >to wonder what it is I don't understand. Testing on a 9500/120, to 
  412. > >which I have limited access, gives the following results for copy 
  413. > >code using 32-bit integer and 64-bit double load and stores, 
  414. > >respectively: 
  415. > > 
  416. > >Asm lvector copy of  1024 doubles in  44.8 nS/acc,  5.4 clocks/acc,  85.1 
  417. MB/s
  418. > >Asm dvector copy of  1024 doubles in  34.1 nS/acc,  4.1 clocks/acc, 111.9 
  419. MB/s
  420.  
  421. > So you are reading 8K and writing 8K as I read it... in a perfect 
  422. > world all of your data would fit (precisely) into the L1 d cache. 
  423. Exactly.  However, I did benchmark a range of copy sizes from 512B to 1MB; the 
  424. quoted 8KB block results were the fastest.  Needless to say the rate for 
  425. larger blocks dropped precipitously as the sizes busted (burst?) the L1 and L2 
  426. caches.
  427.  
  428. > >...so I would expect everything to run at L1 cache rates.  
  429. > Except that you are sharing that L1 with things like interrupt 
  430. > tasks, 68K interrupt tasks (which invoke the emulator causing 
  431. > additional pollution), and so on. 
  432. True.  I would have thought that at least some of my trials would have fit in 
  433. between interrupts, e.g., the critical part of the 8KB case only takes about 
  434. 100uS, and the smaller proportionately less. I also tried back-to-back copy 
  435. calls, producing essentially identical results. I did get _much_ worse results 
  436. when I experimented with using the MacOS Microseconds call for timing, so the 
  437. cache pollution issue is very real.  What is the highest rate interrupt source 
  438. on an idle PowerMac anyway?.  Is Microseconds non-native?  I'm clueless.
  439.  
  440. > Since as far as I know, there is no way to completely shut off 
  441. > PowerPC interrupts, quantifying the effect of background processes on 
  442. > your cache population can be a bit tricky. 
  443. I believe I know how to do it on an 8100 (although not the 9500) so it's 
  444. probably worth a (probable deathcookies) experiment to see it if makes a 
  445. difference there.  I deeply regret having blown up our only hardware prototype 
  446. last month...  Maybe next week I'll have a bare machine again, knock on 
  447. Formica(TM).
  448.  
  449. > >I would naively expect the copy code to average about 1.5 clocks per 
  450. > >load or store.  Instead, my code reports over 4 clocks/access.
  451. > I guess I can work it out ... OK so that's 4 per double 
  452. > read, 4 per double write (on average). 
  453. Yes.
  454.  
  455. > Suggestions: 
  456. >  1. Plot speed versus vector length. Look for nonlinearities. 
  457. >    (deliberately shrink or grow the vector).
  458. For a 9500/120:
  459. 512B    49 MB/s
  460. 1KB     68
  461. 2KB     87
  462. 4KB     109
  463. 8KB     112
  464. 16KB    68
  465. 32KB    62
  466. 64KB    54
  467. 128KB   53
  468. 256KB   40
  469. 512KB   35
  470. 1024KB  32
  471.  
  472. The trends are reasonable, it's just the L1 peak rate that seems very low to 
  473. me.  The 6100 and 8100, on the other hand, have some huge huge anomalous dips 
  474. for 128KB operations, presumably managing to evict the code from both the L1 & 
  475. L2 unified caches in some particularly malign way.
  476.  
  477. >  2. wiggle that 256 byte offset factor some more. or make it zero. 
  478. Zero makes things about 10% slower, but I haven't yet tried other offsets.
  479.  
  480. >  3. think about cache hinting at or near the bottom of the loop. 
  481. >     if for some reason a cache line which you are going to read from 
  482. >     has been dropped, it's good to schedule its re-fetch as far ahead 
  483. >     as possible.
  484. A prior load loop is supposed to have ensured that the source is in the cache, 
  485. but this is a good suggestion to double check that assumption, and probably 
  486. the right thing to do for a general-purpose copy where cache status is 
  487. uncontrolled.  I'll check this out.
  488.  
  489. >  4. I hear Exponential Technology has a faster BiCMOS 604 coming... 
  490. That certainly does look interesting, "only" $14million capitalization, but 
  491. good credentials.  Unfortunately, I have to put something under the tree for 
  492. this Christmas, can't wait for that rosy glow ("Is it Rudolph or is it 
  493. bipolar?") we might see next. :-)
  494.  
  495.  
  496.  
  497. Craig S. Steele - Not yet Institutionalized
  498.  
  499.  
  500.  
  501. +++++++++++++++++++++++++++
  502.  
  503. >From tim@apple.com (Tim Olson)
  504. Date: 7 Dec 1995 03:33:26 GMT
  505. Organization: Apple Computer, Inc. / Somerset
  506.  
  507. In article <9512051830.AA53505@kandor.isi.edu>
  508. steele@isi.edu (Craig S. Steele) writes:
  509.  
  510. > I would naively expect the copy code to average about 1.5 clocks per load or 
  511. > store.  Instead, my code reports over 4 clocks/access.  The code uses the 
  512. > time-base register for timing, which shouldn't cause significant cache 
  513. > disturbance.
  514. > Can anyone contradict, corroborate, or explain my poor results?
  515.  
  516. I did a number of measurements awhile back which showed that a 604 can
  517. perform the loop you gave (without the DCBZ) at about 1.3 cycles per
  518. doubleword loaded or stored -- this was done by measuring the runtime
  519. of copying a 64-byte block over many iterations, so both source and
  520. destination were in the cache.  The DCBZ instruction spends multiple
  521. cycles clearing the allocated cache block, so that will add some
  522. overhead (I don't have my spec with me -- I seem to remember it is 4
  523. cycles), which should bring it to somewhere around 15 cycles per loop
  524. iteration, or about 1.8 cycles per doubleword, which is still far less
  525. than your reported 4 cycles.
  526.  
  527. First, try running without the DCBZ to see if it more closely matches
  528. my results (~1.3 cycles per doubleword); if not, then you might be
  529. forgetting about some multiplication factor when using the timebase
  530. register.  On the 604, it increments every 4th bus clock.
  531.  
  532.         -- Tim Olson
  533.         Apple Computer, Inc. / Somerset
  534.         tim@apple.com
  535.  
  536. +++++++++++++++++++++++++++
  537.  
  538. >From cliffc@ami.sps.mot.com (Cliff Click)
  539. Date: 7 Dec 95 09:23:08
  540. Organization: none
  541.  
  542. steele@isi.edu (Craig S. Steele) writes:
  543.  
  544. Craig S. Steele <steele@isi.edu> wrote: 
  545. >I'm trying to benchmark block copy rates of various sizes for 
  546. >PowerPCs.  My results are disappointing for the 604, and cause me 
  547. >to wonder what it is I don't understand. Testing on a 9500/120, to 
  548. >which I have limited access, gives the following results for copy 
  549. >code using 32-bit integer and 64-bit double load and stores, 
  550. >respectively: 
  551.  
  552. Have you tried using "lmw" and "stmw" instead of "lfd" and "stfd"?
  553. My 604 book sez these are #regs+2 cycles each, whilst the float
  554. operations are 3 cycles each.  For large enough blocks, you should
  555. win on the lmw and stmw.
  556.  
  557. Cliff
  558. --
  559. Cliff Click                  Compiler Researcher & Designer
  560. RISC Software, Motorola      PowerPC Compilers
  561. cliffc@risc.sps.mot.com      (512) 891-7240
  562.  
  563. +++++++++++++++++++++++++++
  564.  
  565. >From tim@apple.com (Tim Olson)
  566. Date: 8 Dec 1995 02:59:57 GMT
  567. Organization: Apple Computer, Inc. / Somerset
  568.  
  569. In article <CLIFFC.95Dec7092308@ami.sps.mot.com>
  570. cliffc@ami.sps.mot.com (Cliff Click) writes:
  571.  
  572. > Have you tried using "lmw" and "stmw" instead of "lfd" and "stfd"?
  573. > My 604 book sez these are #regs+2 cycles each, whilst the float
  574. > operations are 3 cycles each.  For large enough blocks, you should
  575. > win on the lmw and stmw.
  576.  
  577. The lfd instruction has a 3-cycle latency for using the result of the
  578. load in a floating-point operation, but the issue-rate of lfd is one
  579. per cycle.  When pipelined in the manner used in the block copy code,
  580. it can transfer at close to one doubleword per cycle.
  581.  
  582. Load and store multiple instructions can achieve close to one word per
  583. cycle for large transfers, but that is half the bandwith of the
  584. lfd/stfd solution.
  585.  
  586.  
  587.         -- Tim Olson
  588.         Apple Computer, Inc. / Somerset
  589.         tim@apple.com
  590.  
  591. +++++++++++++++++++++++++++
  592.  
  593. >From Mark Williams <Mark@streetly.demon.co.uk>
  594. Date: Thu, 07 Dec 95 18:25:26 GMT
  595. Organization: Streetly Software
  596.  
  597.  
  598. In article <CLIFFC.95Dec7092308@ami.sps.mot.com>, Cliff Click writes:
  599.  
  600. > steele@isi.edu (Craig S. Steele) writes:
  601. > Craig S. Steele <steele@isi.edu> wrote: 
  602. > >I'm trying to benchmark block copy rates of various sizes for 
  603. > >PowerPCs.  My results are disappointing for the 604, and cause me 
  604. > >to wonder what it is I don't understand. Testing on a 9500/120, to 
  605. > >which I have limited access, gives the following results for copy 
  606. > >code using 32-bit integer and 64-bit double load and stores, 
  607. > >respectively: 
  608. > Have you tried using "lmw" and "stmw" instead of "lfd" and "stfd"?
  609. > My 604 book sez these are #regs+2 cycles each, whilst the float
  610. > operations are 3 cycles each.  For large enough blocks, you should
  611. > win on the lmw and stmw.
  612. > Cliff
  613. > --
  614. > Cliff Click                  Compiler Researcher & Designer
  615. > RISC Software, Motorola      PowerPC Compilers
  616. > cliffc@risc.sps.mot.com      (512) 891-7240
  617.  
  618. But surely the point is that lfd & stfd have a _latency_ of 3 cycles, but a
  619. throughput of 1 instruction per cycle, whereas the lmw/stmw have both a latency
  620. and throughput of 1 instruction per #regs+2 cycles. That means the lfd/stfd
  621. method should be able to move (ie load and store) 1 word per cycle, while the
  622. lmw/stmw cannot do better than 1 word every 2 cycles (and even with 28 regs
  623. available it would take 60 cycles to move 28 words).
  624.  
  625. - --------------------------------------
  626. Mark Williams<Mark@streetly.demon.co.uk>
  627.  
  628. +++++++++++++++++++++++++++
  629.  
  630. >From tjrob@bluebird.flw.att.com (Tom Roberts)
  631. Date: Sat, 9 Dec 1995 19:19:22 GMT
  632. Organization: AT&T Bell Laboratories
  633.  
  634. In article <4a89nd$hrp@cerberus.ibmoto.com>, Tim Olson <tim@apple.com> wrote:
  635. >In article <CLIFFC.95Dec7092308@ami.sps.mot.com>
  636. >cliffc@ami.sps.mot.com (Cliff Click) writes:
  637. >
  638. >> Have you tried using "lmw" and "stmw" instead of "lfd" and "stfd"?
  639. >> My 604 book sez these are #regs+2 cycles each, whilst the float
  640. >> operations are 3 cycles each.  For large enough blocks, you should
  641. >> win on the lmw and stmw.
  642. >
  643. >The lfd instruction has a 3-cycle latency for using the result of the
  644. >load in a floating-point operation, but the issue-rate of lfd is one
  645. >per cycle.  When pipelined in the manner used in the block copy code,
  646. >it can transfer at close to one doubleword per cycle.
  647. >
  648. >Load and store multiple instructions can achieve close to one word per
  649. >cycle for large transfers, but that is half the bandwith of the
  650. >lfd/stfd solution.
  651.  
  652. In practical systems, memory bandwidth is MUCH more important than
  653. the number of instructions used or their throughput or latency.
  654. (This assumes that the data actually resides in memory, not just in the
  655. cache. This also assumes a "long" loop, so the code is in the icache.)
  656.  
  657. In systems which run the 604 at 1:1 clocking (i.e. internal CPU clock
  658. equals external bus clock), memory bandwidth can be 2-4 times slower than
  659. simple calculations. This is due to cache-access limitations and the
  660. fact that both the CPU and the bus access unit are competing for
  661. access to the cache. In this mode the memory essentially NEVER
  662. overlaps address and data tenures on the bus (halving memory bandwidth);
  663. there are usually several bus clocks between succesive cycles, reducing
  664. bandwidth even more.
  665.  
  666. With 1.5:1 clocking this effect is reduced -- the cache can handle
  667. one access per internal clock, so there is a cycle available to the
  668. CPU between every 2 bus accesses. At 2:1 this effect should disappear,
  669. as the CPU can get every other cycle, and keep up with the memory
  670. bus bandwidth.
  671.  
  672. Note that only recently have 604 chips been shipping which can go 1.5:1
  673. at 66 MHz bus clock.
  674.  
  675. Tom Roberts     tjrob@iexist.att.com
  676.  
  677. ---------------------------
  678.  
  679. >From ralf@lexis-nexis.com (Ralf Grisard)
  680. Subject: Choosing a Help Authoring Tool
  681. Date: 30 Nov 1995 15:31:01 GMT
  682. Organization: Lexis-Nexis
  683.  
  684. I'm a technical writer with some experience creating electronic helps 
  685. for MS Windows applications. I've also written balloon help and some 
  686. technologically primitive application help for one Macintosh 
  687. application. Now I'm researching the help possibilities for the next 
  688. version of that Mac app. Here's a list of some of the factors I'm 
  689. considering:
  690.  
  691. * Is there a Mac help tool/system that's evolving into the "standard"?
  692.  
  693. * How well is Apple Guide being accepted by the developer and user 
  694. communities?
  695.  
  696. * When will there actually be a version of Apple Guide available that 
  697. is compatible with System 7.0/7.1?
  698.  
  699. * Are there tools/systems other than Apple Guide (such as EHelp) that 
  700. are well regarded by Mac users? For example, the help for the latest 
  701. version of ClarisWorks for Macintosh has received some praise.
  702.  
  703. * Which tools are suitable for use by non-programmers (like technical 
  704. writers)?
  705.  
  706. * What's the learning curve for the tool?
  707.  
  708. * How much collaboration does a tool require between the programmer 
  709. and the help author?
  710.  
  711. * How large are the final help files? How quickly to they respond to 
  712. the user?
  713.  
  714. * How expensive is the tool? (The complete EHelp package costs about 
  715. $2500 per copy.)
  716.  
  717. * Does use of the tool involve royalty/licensing/distribution fees?
  718.  
  719. And so on. Any information you could share with me would be much 
  720. appreciated. Thanks in advance.
  721. -- 
  722. Ralf Grisard
  723. ralf@lexis-nexis.com
  724. LEXIS-NEXIS, Technical Communications, P.O. Box 933, Dayton, OH 45401
  725. voice: 513-865-7314  fax: 513-865-1655
  726.  
  727.  
  728. +++++++++++++++++++++++++++
  729.  
  730. >From alain@cs.uchicago.edu (Alain Roy)
  731. Date: Thu, 30 Nov 1995 17:20:48 GMT
  732. Organization: It lurks in the night
  733.  
  734. In article <49ki7n$493@meaddata.meaddata.com>, ralf@lexis-nexis.com (Ralf
  735. Grisard) wrote:
  736.  
  737. >* When will there actually be a version of Apple Guide available that 
  738. >is compatible with System 7.0/7.1?
  739.  
  740. Apple Guide 2.0 is out and supports 7.0/7.1. Check out:
  741.  
  742. http://dev.info.apple.com/appledirections/dec95/appleguide.html
  743.  
  744. (They provide a pointer to download AG 2.0)
  745.  
  746. Apple has "Guide Maker". I've never used it.
  747.  
  748. At the info-mac archive in the "dev" directory, you can find
  749. "guide-composer-10-demo.hqx" which is a demo of a tool to make apple guide
  750. files. It claims to be easy, but I've never used it.
  751.  
  752. -alain
  753.  
  754. +++++++++++++++++++++++++++
  755.  
  756. >From Steve@emer.com (Steve Wilson)
  757. Date: 30 Nov 1995 17:49:32 GMT
  758. Organization: Emergent Behavior
  759.  
  760.  
  761. > * How well is Apple Guide being accepted by the developer and user 
  762. > communities?
  763.  
  764. I think it is very cool.  Everyone should be using it.
  765.  
  766. > * When will there actually be a version of Apple Guide available that 
  767. > is compatible with System 7.0/7.1?
  768.  
  769. It is already here.  You can get Appleguide 2.0 off apple's web page.  It
  770. will work with system 7.
  771.  
  772. > * Are there tools/systems other than Apple Guide (such as EHelp) that 
  773. > are well regarded by Mac users? For example, the help for the latest 
  774. > version of ClarisWorks for Macintosh has received some praise.
  775.  
  776. I persnally hate Claris' online help.   It was created with QuickView. 
  777. QuickView was also used to create the Toolbox Assistant, which I love, so
  778. it probably isn't the tool's fault.
  779.  
  780. > * Which tools are suitable for use by non-programmers (like technical 
  781. > writers)?
  782.  
  783. If you're going to use AppleGuide you should get Danny Goodman's book
  784. which includes a nice tool to get you started.  It works well for
  785. non-programmers.
  786.  
  787.  
  788. > * How expensive is the tool? (The complete EHelp package costs about 
  789. > $2500 per copy.)
  790.  
  791. You can get the book( which includes the tool) for about $30-$40.
  792.  
  793. Steve Wilson
  794. Emergent Behavior
  795. (415) 494-6763
  796. Steve@emer.com
  797.  
  798. +++++++++++++++++++++++++++
  799.  
  800. >From paquette@metrowerks.ca (Marc Paquette)
  801. Date: 1 Dec 1995 19:56:04 GMT
  802. Organization: Metrowerks Inc.
  803.  
  804. In article <49kiot$493@meaddata.meaddata.com>, ralf@lexis-nexis.com (Ralf
  805. Grisard) wrote:
  806.  
  807. Metrowerks, the company I work at, has been creeping along this path for
  808. some time. Here is what I have to offer. The Mac OS help jungle can be
  809. treacherous--watch your step:
  810.  
  811. > * Is there a Mac help tool/system that's evolving into the "standard"?
  812.  
  813. Balloon help. Apple Guide _could_ also be considered a "standard," but
  814. developers seem to be slow to accept it, although it's becoming more
  815. popular lately.
  816.  
  817. > * How well is Apple Guide being accepted by the developer and user 
  818. > communities?
  819.  
  820. See above. Metrowerks doesn't use Apple Guide so I can't give accurate
  821. answers about it. We don't use Apple Guide partly because the tools aren't
  822. quite ready yet, but mostly because our documentation is heavy on the
  823. technical reference side which is inappropriate for AG. However, some
  824. people at Apple have attentively bent theirs ears for us on making AG more
  825. reference-happy. The results remain to be seen.
  826.  
  827. > * Are there tools/systems other than Apple Guide (such as EHelp) that 
  828. > are well regarded by Mac users? For example, the help for the latest 
  829. > version of ClarisWorks for Macintosh has received some praise.
  830.  
  831. I don't have experience in producing doc for EHelp.
  832.  
  833. I'm told that Claris uses a version of QuickView for some of its software.
  834. So does Apple for its Toolbox Assistant software. Metrowerks is also using
  835. QuickView for its on-line help. QuickView is a Microsoft help-compatible
  836. viewer.
  837.  
  838. Metrowerks also uses Adobe Acrobat, but a lot of users complain about its
  839. large memory footprint, its need for ATM, and incompatibilities with
  840. QuickDraw GX.
  841.  
  842. There's also HTML. Metrowerks is looking into it, but solid HTML tools for
  843. the Mac aren't around yet.
  844.  
  845. > * Which tools are suitable for use by non-programmers (like technical 
  846. > writers)?
  847.  
  848. [rant on]
  849. I wish tech writers had nifty documentation development tools like
  850. programmers have nifty software development tools! Such tools would save
  851. me so much time and effort. I'd rather spend my time developing useful,
  852. accurate doc rather than fiddling with the silly details of how to deliver
  853. the doc to the user.
  854. [rant off]
  855.  
  856. Metrowerks produces its documentation using Framemaker on Mac OS machines.
  857. We use whatever converters and translators there are for FrameMaker to
  858. convert to RTF, Acrobat, etc. It's straightforward stuff.
  859.  
  860. We use Resorcerer, a resource editor, for balloon help. It's not an easy
  861. way to go, but we get the job done.
  862.  
  863. > * What's the learning curve for the tool?
  864.  
  865. For FrameMaker, things are pretty simple: Create FrameMaker document,
  866. save/print the document in a specific format, put that file through a
  867. translator to generate the online help document. If you know FrameMaker,
  868. you've got it clinched. 
  869.  
  870. Resorcerer and the Help Manager's strange interactions with the Dialog
  871. Manager results in some frustrating situations until you get the hang of
  872. it.
  873.  
  874. > * How much collaboration does a tool require between the programmer 
  875. > and the help author?
  876.  
  877. For balloon help, the collaboration sometimes has to be pretty tight. Even
  878. more so, IMHO, for Apple Guide.
  879.  
  880. For FrameMaker, none once you're all set up.
  881.  
  882. > * How large are the final help files? How quickly to they respond to 
  883. > the user?
  884.  
  885. A QV file is quite reasonable. The 1300 page PowerPlant library reference,
  886. produced by Metrowerks is 6.2 Mbytes. QV is responsive. We've had no
  887. complaints about its performance, and Altura was quick to improve parts of
  888. the UI at user's requests.
  889.  
  890. Acrobat is about the same as a QV database. IMHO, Acrobat is OK when
  891. reading from a hard drive, but it can be slow when reading from a CD-ROM.
  892. However, proper documentation design can dramatically improve Acrobat's
  893. responsiveness. Metrowerks is still working on this.
  894.  
  895. I don't have any numbers for the HTML version of the PowerPlant reference
  896. (it doesn't exist). For HTML conversion I believe we've tried some of the
  897. freeware/shareware translators available.
  898.  
  899. > * How expensive is the tool? (The complete EHelp package costs about 
  900. > $2500 per copy.)
  901.  
  902. Altura Software, Inc.
  903. 510 Lighthouse Ave., Suite 5
  904. Pacific Grove, CA 93950
  905.  
  906. Voice:408.655.8005
  907. FAX:408.655.9663  
  908.  
  909. Disclaimer: Some of these opinions are my own, not Metrowerks. All of
  910. these opinions are based on my experiences as a member of the Metrowerks
  911. documentation team.
  912.  
  913. Regards,
  914.  
  915. Marc.
  916.  
  917. - -
  918. Marc Paquette
  919. Lead Lead Pipe Fitter
  920. Metrowerks Inc.
  921.  
  922. +++++++++++++++++++++++++++
  923.  
  924. >From Jeff Benjamin <stepup@onramp.net>
  925. Date: 1 Dec 1995 15:54:16 GMT
  926. Organization: StepUp Software
  927.  
  928. ralf@lexis-nexis.com (Ralf Grisard) wrote:
  929.  
  930. >
  931. >* Is there a Mac help tool/system that's evolving into the "standard"?
  932. >
  933.  
  934. Only time will tell. It seems that Apple Guide is growing 
  935. very well.
  936.  
  937. >
  938. >* When will there actually be a version of Apple Guide available that 
  939. >is compatible with System 7.0/7.1?
  940.  
  941. Today. Apple Guide 2.0 (shipping).
  942.  
  943.  
  944. >* Which tools are suitable for use by non-programmers (like technical 
  945. >writers)? * What's the learning curve for the tool?
  946. >
  947.  
  948. I suggest you check out our Guide Composer (see Web site below).
  949.  
  950. >* How much collaboration does a tool require between the programmer 
  951. >and the help author?
  952.  
  953. It depends on the level of interaction between the help system and
  954. the program. For Apple Guide, it could be as little as NO 
  955. INTERACTION. If your app is AppleScript-able, you can do alot
  956. w/o the programmer.
  957.  
  958. >
  959. >* How expensive is the tool? (The complete EHelp package costs about 
  960. >$2500 per copy.)
  961.  
  962. Guide Composer is $99. No other fees.
  963.  
  964. >* Does use of the tool involve royalty/licensing/distribution fees?
  965.  
  966. For Guide Composer, no.
  967.  
  968. Good luck!
  969.  
  970.  
  971. - -----------------------------------------------
  972. +                Jeff Benjamin                         
  973. +                StepUp Software                    
  974. +                stepup@onramp.net
  975. +                http://rampages.onramp.net/~stepup/
  976. - -----------------------------------------------
  977.  
  978.  
  979.  
  980. +++++++++++++++++++++++++++
  981.  
  982. >From billf@scruznet.com (Bill Foster)
  983. Date: Mon, 04 Dec 1995 21:32:34 -0800
  984. Organization: Passion Pacific
  985.  
  986. In article <49kinl$493@meaddata.meaddata.com>, ralf@lexis-nexis.com (Ralf
  987. Grisard) wrote:
  988.  
  989. > Now I'm researching the help possibilities for the next 
  990. > version of that Mac app.
  991. > And so on. Any information you could share with me would be much 
  992. > appreciated. Thanks in advance.
  993. > -- 
  994. > Ralf Grisard
  995. > ralf@lexis-nexis.com
  996. > LEXIS-NEXIS, Technical Communications, P.O. Box 933, Dayton, OH 45401
  997. > voice: 513-865-7314  fax: 513-865-1655
  998.  
  999. You might want to check out
  1000.  
  1001.     http://www.guideworks.com
  1002.  
  1003. This site has a lot of information about Apple Guide.
  1004.  
  1005. Apple Guide 2.0 now supports System 7.0/7.1. It is available from the
  1006. guideWorks site as is the GuideMaker application for compiling guides. I'm
  1007. not sure about licensing but its either free or cheap.
  1008.  
  1009. It's pretty easy to put together a basic guide. You do not need to change
  1010. your application unless you want to add features.
  1011.  
  1012. ================================================
  1013. Bill Foster            Passion Pacific Solutions
  1014. billf@scruznet.com         Santa Cruz, Califonia
  1015. ================================================
  1016.  
  1017. +++++++++++++++++++++++++++
  1018.  
  1019. >From alspaugh@showme.missouri.edu (Bruce Alspaugh)
  1020. Date: Thu, 07 Dec 1995 14:25:35 -0600
  1021. Organization: SchoolWare
  1022.  
  1023. In article <49ki7n$493@meaddata.meaddata.com>, ralf@lexis-nexis.com (Ralf
  1024. Grisard) wrote:
  1025.  
  1026. > * When will there actually be a version of Apple Guide available that 
  1027. > is compatible with System 7.0/7.1?
  1028.  
  1029.    AppleGuide 2.0, which supports system 7.0 and 7.1, is available now and
  1030. can be ftp'ed from:
  1031.  
  1032. ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/System_Software_Extensions/Apple_Guide_Authoring_Kit. 
  1033.  
  1034.  
  1035. If you want further information on AppleGuide, I suggest you check out the
  1036. GuideWorks home page:
  1037.  
  1038. http://www.guideworks.com/
  1039.  
  1040.    You can also subscribe to an apple-guide mailing list to answer your
  1041. technical questions.  Send an e-mail to listserv@list.peter.com.au with
  1042. the command, subscribe apple-guide <your first name> <your last name> in
  1043. the subject header and the body of the message.
  1044.  
  1045. Hope this helps,
  1046.  
  1047.  
  1048. Bruce Alspaugh
  1049. alspaugh@showme.missouri.edu
  1050.  
  1051. +++++++++++++++++++++++++++
  1052.  
  1053. >From ldo@waikato.ac.nz (Lawrence D'Oliveiro)
  1054. Date: Fri, 08 Dec 1995 17:42:09 +1300
  1055. Organization: University of Waikato
  1056.  
  1057. In article <paquette-0112951500140001@sigma.metrowerks.ca>,
  1058. paquette@metrowerks.ca (Marc Paquette) wrote:
  1059.  
  1060. >Metrowerks also uses Adobe Acrobat, but a lot of users complain about its
  1061. >large memory footprint, its need for ATM, and incompatibilities with
  1062. >QuickDraw GX.
  1063.  
  1064. I believe Adobe's PDF-generation tools are GX-incompatible, however
  1065. Acrobat Reader 2.1 seems to work OK (most of the time) with GX.
  1066.  
  1067. Under GX, as you know, you can print from any application to a "Portable
  1068. Digital Document" (PDD). This is viewable and printable at full resolution
  1069. on any printer from any Mac with GX installed. I've also been working on a
  1070. tool to generate PDF files from these PDDs--no support for hyperlinks and
  1071. annotations as yet, though. If anybody's interested, they can try out a
  1072. prerelease version at
  1073. <ftp://sumex-aim.stanford.edu/info-mac/gst/grf/tumbler-06d2.hqx>. Feel
  1074. free to send me your comments.
  1075.  
  1076. Lawrence
  1077. supporter of the QuickDraw GX Fan Club at <http://www.ixmedia.com/quickgx/>
  1078.  
  1079. ---------------------------
  1080.  
  1081. >From Frank Kane <fkane@tiac.net>
  1082. Subject: Events vs. GetKeys
  1083. Date: Sat, 02 Dec 1995 14:54:14 +0000
  1084. Organization: Cerberus Development
  1085.  
  1086. I hear mixed messages about using GetKeys() vs. the Event Manager to 
  1087. read user input during a game.
  1088.  
  1089. I used GetKeys in my first game, and I'm using events in my current 
  1090. game.  Honestly, I don't think it makes much of a difference in 
  1091. terms of speed.
  1092.  
  1093. Using the Event Manager has several advantages, such as ensuring 
  1094. that you don't miss a keystroke if the user hits a key real fast 
  1095. (it's also a heckuva lot easier.)  It just seems safer, and more 
  1096. friendly to the customer.  Plus it seems like a safer bet that 
  1097. future game controllers will work properly through the event queue.
  1098.  
  1099. Am I missing the boat altogether by using the Event Manager?  Is 
  1100. there some good reason to use GetKeys that I don't know about?
  1101.  
  1102. Thanks,
  1103. -Frank Kane
  1104. Cerberus Development
  1105. http://www.transy.edu/~cerbdev/Mac_Division/MacHome.html
  1106.  
  1107. +++++++++++++++++++++++++++
  1108.  
  1109. >From kbs3387@silver.sdsmt.edu (Kevin Stone)
  1110. Date: 2 Dec 1995 21:00:05 GMT
  1111. Organization: South Dakota School of Mines and Technology
  1112.  
  1113. : Am I missing the boat altogether by using the Event Manager?  Is 
  1114. : there some good reason to use GetKeys that I don't know about?
  1115.  
  1116.    Can you read multiple keys this way?
  1117.    My understanding is that when an event is triggered, it's sent to the 
  1118.    Event Manager queue.  It waits their until you use GetNextEvent or 
  1119.    WaitNextEvent.  You can see what the next event is... whether it's a 
  1120.    key hit or a mouse click or whatever, and you can check to see which 
  1121.    modifier keys are down, but it dosn't look like you can't see if two 
  1122.    character keys are down at the same time.
  1123.  
  1124.    I don't know... I might be missing something here.  Personaly, I 
  1125.    havn't had any problems with GetKeys.
  1126.  
  1127. BAS
  1128.  
  1129.  
  1130. +++++++++++++++++++++++++++
  1131.  
  1132. >From lewistotle@emf.net (John Lewis)
  1133. Date: Sat, 02 Dec 1995 14:02:16 -0800
  1134. Organization: me
  1135.  
  1136. In article <30C06896.8A5@tiac.net>, fkane@tiac.net wrote:
  1137.  
  1138. > Using the Event Manager has several advantages, such as ensuring 
  1139. > that you don't miss a keystroke if the user hits a key real fast 
  1140. > (it's also a heckuva lot easier.)  It just seems safer, and more 
  1141. > friendly to the customer.  Plus it seems like a safer bet that 
  1142. > future game controllers will work properly through the event queue.
  1143. > Am I missing the boat altogether by using the Event Manager?  Is 
  1144. > there some good reason to use GetKeys that I don't know about?
  1145.  
  1146. I'm currently working on a project that needs to know when the user
  1147. releases a key as well. I started out using the event manager and watching
  1148. for keyUp events. (Yes I did call SetEventMask)
  1149.  
  1150. This worked fine except when I was running under the debugger. Then, for a
  1151. reason I still haven't figured out, I wouldn't receive keyUp events. For
  1152. this reason, I ended up switching to GetKeys.
  1153.  
  1154. The keyUp problem wouldn't happen all the time, though, and Metrowerks has
  1155. been notified of the problem.
  1156.  
  1157. Later.
  1158.  
  1159. - ------------------------------------------------------------------------
  1160. John "I'd rather be skydiving" Lewis |#include "stdsig.BS" | This space  |
  1161. lewistotle@emf.net    <- prefered    |Blue Skies           | available   |
  1162. lewistotle@maxis.com work(unreliable)|USPA87419, C-22826   | for rent.   |
  1163. lewistotle@aol.com    <- rarely      |Slider - '92 BMW K75s| Inquire     |
  1164. |http://www.emf.net/~lewistot        |<fnord>              | within      |
  1165.  
  1166. +++++++++++++++++++++++++++
  1167.  
  1168. >From Frank Kane <fkane@tiac.net>
  1169. Date: Sun, 03 Dec 1995 09:38:16 +0000
  1170. Organization: Cerberus Development
  1171.  
  1172. > The keyUp problem wouldn't happen all the time, though, and Metrowerks has
  1173. > been notified of the problem.
  1174.  
  1175. Glad you posted this...  I've been having the same problems with KeyUps as 
  1176. well, but I thought it was some horribly elusive bug in my code.  Now at least 
  1177. I know I'm not to blame...
  1178.  
  1179. Regarding the previous post -- yes, you can tell if two keys are down 
  1180. simultaneously using events, *if* you track KeyUps as well as KeyDowns.  Just 
  1181. don't try it using the MW debugger :-)
  1182.  
  1183. Thanks,
  1184. -Frank
  1185.  
  1186. +++++++++++++++++++++++++++
  1187.  
  1188. >From tgooding@iastate.edu (Tom Gooding)
  1189. Date: Sun, 03 Dec 1995 20:46:47 -0600
  1190. Organization: Iowa State University, Ames, Iowa
  1191.  
  1192. In article <30C06896.8A5@tiac.net>, fkane@tiac.net wrote:
  1193.  
  1194. > I hear mixed messages about using GetKeys() vs. the Event Manager to 
  1195. > read user input during a game.
  1196. > I used GetKeys in my first game, and I'm using events in my current 
  1197. > game.  Honestly, I don't think it makes much of a difference in 
  1198. > terms of speed.
  1199. > Using the Event Manager has several advantages, such as ensuring 
  1200. > that you don't miss a keystroke if the user hits a key real fast 
  1201. > (it's also a heckuva lot easier.)  It just seems safer, and more 
  1202. > friendly to the customer.  Plus it seems like a safer bet that 
  1203. > future game controllers will work properly through the event queue.
  1204. > Am I missing the boat altogether by using the Event Manager?  Is 
  1205. > there some good reason to use GetKeys that I don't know about?
  1206.  
  1207. My experience using the Event Manager has been somewhat rocky.  It has a
  1208. few problems.
  1209. 1) Reading Multiple keys becomes difficult
  1210. 2) The speed that you can read keys is limited by the keyboard repeat rate.
  1211.  
  1212. I dunno, maybe I'm missing some function call.  If speed isn't important,
  1213. use GetNextEvent or WaitNextEvent.
  1214.  
  1215. Tom Gooding
  1216. tgooding@iastate.edu
  1217. Computer Engineering 4
  1218.  
  1219. +++++++++++++++++++++++++++
  1220.  
  1221. >From ingemar@lysator.liu.se (Ingemar Ragnemalm)
  1222. Date: 4 Dec 1995 09:34:14 GMT
  1223. Organization: (none)
  1224.  
  1225. Frank Kane <fkane@tiac.net> writes:
  1226.  
  1227. >I hear mixed messages about using GetKeys() vs. the Event Manager to 
  1228. >read user input during a game.
  1229. Of course you get mixed messages! Different games need different solutions.
  1230.  
  1231. >I used GetKeys in my first game, and I'm using events in my current 
  1232. >game.  Honestly, I don't think it makes much of a difference in 
  1233. >terms of speed.
  1234.  
  1235. It makes a big difference if you use WNE with a sleep time > 0, or have
  1236. lots of applications in the background.
  1237.  
  1238. >Using the Event Manager has several advantages, such as ensuring 
  1239. >that you don't miss a keystroke if the user hits a key real fast 
  1240. >(it's also a heckuva lot easier.)  It just seems safer, and more 
  1241. >friendly to the customer.  Plus it seems like a safer bet that 
  1242. >future game controllers will work properly through the event queue.
  1243.  
  1244. Also, with events you *know* what key the user has hit. With GetKeys,
  1245. you only have the key code, you don't know what key it is. Assuming that
  1246. the key codes are the same on all keyboards is foolish. Dark Forces
  1247. does it, but that's no excuse. (The "+" key shinks the map and the "'"
  1248. key expands it - not good at all!)
  1249.  
  1250. >Am I missing the boat altogether by using the Event Manager?  Is 
  1251. >there some good reason to use GetKeys that I don't know about?
  1252.  
  1253. Well, as long as you just want the keyDowns, that is, if you just want to
  1254. know when a key is hit, not for how long it stays down, it is ok. I never
  1255. felt I could trust every keyDown to be matched by a keyUp.
  1256.  
  1257. --
  1258. - -
  1259. Ingemar Ragnemalm, PhD
  1260. Image processing, Mac shareware games
  1261. E-mail address: ingemar@isy.liu.se or ingemar@lysator.liu.se
  1262.  
  1263. +++++++++++++++++++++++++++
  1264.  
  1265. >From jmunkki@gamma.hut.fi (Juri Munkki)
  1266. Date: 4 Dec 1995 17:12:32 GMT
  1267. Organization: Helsinki University of Technology
  1268.  
  1269. In article <49ufan$kgj@newsy.ifm.liu.se> ingemar@lysator.liu.se (Ingemar Ragnemalm) writes:
  1270. >Frank Kane <fkane@tiac.net> writes:
  1271. >>I used GetKeys in my first game, and I'm using events in my current 
  1272. >>game.  Honestly, I don't think it makes much of a difference in 
  1273. >>terms of speed.
  1274.  
  1275. >It makes a big difference if you use WNE with a sleep time > 0, or have
  1276. >lots of applications in the background.
  1277.  
  1278. During games, I never call WNE. I may call GetNextEvent, if the user
  1279. has background processing enabled, but the best thing is usually to
  1280. call only GetOSEvent, since it doesn't allow any background processing.
  1281.  
  1282. >>Using the Event Manager has several advantages, such as ensuring 
  1283. >>that you don't miss a keystroke if the user hits a key real fast 
  1284. >>(it's also a heckuva lot easier.)  It just seems safer, and more 
  1285. >>friendly to the customer.  Plus it seems like a safer bet that 
  1286. >>future game controllers will work properly through the event queue.
  1287.  
  1288. These are all true. That's why I converted from GetKeys to GetOSEvent.
  1289. The main bother is that you don't get keyUps and keyDowns for modifier
  1290. keys and they are usually the best for games, so one has to write some
  1291. additional code to handle them and it's still possible for the game to
  1292. miss a quick tap on a modifier key.
  1293.  
  1294. >Also, with events you *know* what key the user has hit. With GetKeys,
  1295. >you only have the key code, you don't know what key it is. Assuming that
  1296. >the key codes are the same on all keyboards is foolish. Dark Forces
  1297. >does it, but that's no excuse. (The "+" key shinks the map and the "'"
  1298. >key expands it - not good at all!)
  1299.  
  1300. Keys should be configurable. I think it is better to attach the functions
  1301. to virtual keycodes than characters. You just have to remember that the
  1302. layouts may change and some keys may not exist at all or some extra keys
  1303. will exist on some keyboards.
  1304.  
  1305. I believe that I have the perfect solution to keyboard configuration,
  1306. but most of you will have to wait until the game is released before you
  1307. can judge if it does it right. It's a very compact, easily
  1308. reconfigurable library, so I may offer it to other developers as well,
  1309. if there is interest.
  1310.  
  1311. >Well, as long as you just want the keyDowns, that is, if you just want to
  1312. >know when a key is hit, not for how long it stays down, it is ok. I never
  1313. >felt I could trust every keyDown to be matched by a keyUp.
  1314.  
  1315. Interestingly, it seems you can trust keyUps to be posted for each
  1316. keyDown. At least it works for me. You can also get more accurate
  1317. timing information with events, since every event is time stamped
  1318. with a tickcount.
  1319.  
  1320. The thing to remember with events is that you only get one event at a time
  1321. even when there might be a dozen queued up. Each time you look for keyboard
  1322. activity, go through the whole queue. A game that only allows one keypress
  1323. per frame will be extremely irritating to most players.
  1324.  
  1325. -- 
  1326. Juri Munkki jmunkki@iki.fi      In cyberspace everyone can hear you scream.
  1327. http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.
  1328.  
  1329. +++++++++++++++++++++++++++
  1330.  
  1331. >From jesjones@halcyon.com (Jesse Jones)
  1332. Date: 4 Dec 1995 01:28:06 GMT
  1333. Organization: Edmark
  1334.  
  1335. In article <lewistotle-0212951402160001@emf2-212.emf.net>,
  1336. lewistotle@emf.net (John Lewis) wrote:
  1337.  
  1338. [snip]
  1339.  
  1340. > I'm currently working on a project that needs to know when the user
  1341. > releases a key as well. I started out using the event manager and watching
  1342. > for keyUp events. (Yes I did call SetEventMask)
  1343. > This worked fine except when I was running under the debugger. Then, for a
  1344. > reason I still haven't figured out, I wouldn't receive keyUp events. For
  1345. > this reason, I ended up switching to GetKeys.
  1346.  
  1347. [snip]
  1348.  
  1349. For some reason the system event mask isn't reset when apps are switched
  1350. out and in. You need to reset the mask when your app is switched in and
  1351. change it back to the default before quitting.
  1352.  
  1353.   --Jesse
  1354.  
  1355. +++++++++++++++++++++++++++
  1356.  
  1357. >From hnsngr@sirius.com (Ron Hunsinger)
  1358. Date: Mon, 04 Dec 1995 20:59:55 -0800
  1359. Organization: ErsteSoft
  1360.  
  1361. In article <tgooding-0312952046470001@helser196.res.iastate.edu>,
  1362. tgooding@iastate.edu (Tom Gooding) wrote:
  1363.  
  1364. > In article <30C06896.8A5@tiac.net>, fkane@tiac.net wrote:
  1365. > > Using the Event Manager has several advantages, such as ensuring 
  1366. > > that you don't miss a keystroke if the user hits a key real fast 
  1367. > > (it's also a heckuva lot easier.)  It just seems safer, and more 
  1368. > > friendly to the customer.
  1369.  
  1370. Hear, hear! I really hate games that miss keystrokes because they're using
  1371. GetKeys. And from a progamming viewpoint, I agree that events are a lot
  1372. cleaner.
  1373.  
  1374. One advantage you overlooked is that the Event Manager understands about
  1375. multiple keyboards. Admittedly, not many users have them, but the fact
  1376. that GetKeys is making an unwarranted assumption strengthens the feeling
  1377. that it's really just a kludge.
  1378.  
  1379. > My experience using the Event Manager has been somewhat rocky.  It has a
  1380. > few problems.
  1381. > 1) Reading Multiple keys becomes difficult
  1382.  
  1383. Not really. Enable keyUp events (and mask out autoKey events instead), and
  1384. you will get exactly the same information: a keyDown every time a bit is
  1385. set in the keyboard table, and a keyUp every time a bit is cleared. Except
  1386. for modifier keys, of course, which you have to track separately from the
  1387. modifiers field of each event.
  1388.  
  1389. > 2) The speed that you can read keys is limited by the keyboard repeat rate.
  1390.  
  1391. No difference here. The information returned by GetKeys only changes this
  1392. fast anyway. The keyboard itself only sends back (the equivalent of)
  1393. keyDown and keyUp events, which the event manager uses to maintain the
  1394. table that GetKeys returns. 
  1395.  
  1396. You can maintain that table just as well, and if you do it yourself you're
  1397. sure to catch rapid keystrokes.
  1398.  
  1399. > I dunno, maybe I'm missing some function call.  If speed isn't important,
  1400. > use GetNextEvent or WaitNextEvent.
  1401.  
  1402. I can't believe that speed would ever be that important. The keyboard is
  1403. only scanned 60 times a second, and the cost of GetNextEvent is much
  1404. smaller than this. 
  1405.  
  1406. If absolutely necessary, you can monitor Ticks so you only call GNE/WNE
  1407. that often. The test would be: don't call GNE if the last event was a
  1408. nullEvt and the TickCount hasn't changed since then. This allows for the
  1409. possibility that multiple events could be posted in one tick, while still
  1410. holding the overhead down to at most one superflous call per tick.
  1411.  
  1412. -Ron Hunsinger
  1413.  
  1414. +++++++++++++++++++++++++++
  1415.  
  1416. >From johnb@hk.super.net (John W. Blackburne)
  1417. Date: Tue, 05 Dec 1995 18:11:57 +0800
  1418. Organization: Tempest
  1419.  
  1420. Not so much a reply but a couple of observations.
  1421.  
  1422. First is that one problem with events is as far as I can tell you won't
  1423. receive notification of a user pressing a modifier key. With most
  1424. keyboards having dozens of other keys to choose from this would not be
  1425. important, except Apple only guarantees that at at most 2 non-modifier
  1426. keys will be properly sensed at once. Modern action games can easily have
  1427. four or five keys in use at once, so function most reliably using
  1428. modifiers for many of their functions.
  1429.  
  1430. This is assuming the 'at most 2 keys plus modifiers' limit still applies.
  1431. I think this first appeared in Inside Macintosh IV or V, and I've not seen
  1432. anything about it since then. We've been through a few System software and
  1433. hardware revisions since then, so does this limit still apply ?
  1434.  
  1435. Also the most significant problem with GetKeys, that it can't poll
  1436. multiple devices, e.g. a keyboard and seperate keypad, can be fixed using
  1437. a GetKeys replacement routine, ADB Key Spy, which appeared on the November
  1438. Developer CD.
  1439.  
  1440. John
  1441. -- 
  1442. John Blackburne,                     johnb@tempest.net.hk
  1443. Programmer  Asia, Inc. Online:       http://www.asia-inc.com
  1444. Technology consultant and trainer:   http://www.hk.super.net/~johnb
  1445.  
  1446. +++++++++++++++++++++++++++
  1447.  
  1448. >From pottier@brick.ens.fr (Francois Pottier)
  1449. Date: 5 Dec 1995 15:06:29 GMT
  1450. Organization: Ecole Normale Superieure, Paris
  1451.  
  1452. In article <49va60$v7l@nntp.hut.fi>, Juri Munkki <jmunkki@gamma.hut.fi> wrote:
  1453.  
  1454. >Keys should be configurable. I think it is better to attach the functions
  1455. >to virtual keycodes than characters.
  1456.  
  1457. I agree, because people with foreign keyboards will have trouble if functions
  1458. are attached to characters which are obtained through weird combinations. The 
  1459. only problem is then how to tell the user which key does which. For instance,
  1460. the docs for A-10 say "press M to arm the cannon" but I actually have to press
  1461. "," because I have a French keyboard. The location of the key on the keyboard
  1462. is the same, but a user who has never used an American keyboard is helplessly
  1463. lost.
  1464.  
  1465. -- 
  1466. Francois
  1467. pottier@dmi.ens.fr
  1468. http://www.eleves.ens.fr:8080/home/pottier/
  1469.  
  1470. +++++++++++++++++++++++++++
  1471.  
  1472. >From jmunkki@gamma.hut.fi (Juri Munkki)
  1473. Date: 5 Dec 1995 20:13:08 GMT
  1474. Organization: Helsinki University of Technology
  1475.  
  1476. In article <4a1n5l$p2l@nef.ens.fr> pottier@brick.ens.fr (Francois Pottier) writes:
  1477. >In article <49va60$v7l@nntp.hut.fi>, Juri Munkki <jmunkki@gamma.hut.fi> wrote:
  1478. >
  1479. >>Keys should be configurable. I think it is better to attach the functions
  1480. >>to virtual keycodes than characters.
  1481. >
  1482. >I agree, because people with foreign keyboards will have trouble if functions
  1483. >are attached to characters which are obtained through weird combinations. The 
  1484. >only problem is then how to tell the user which key does which. For instance,
  1485. >the docs for A-10 say "press M to arm the cannon" but I actually have to press
  1486. >"," because I have a French keyboard. The location of the key on the keyboard
  1487. >is the same, but a user who has never used an American keyboard is helplessly
  1488. >lost.
  1489.  
  1490. You can use KeyTrans to translate key codes to characters. Optimally you
  1491. would maintain a set of strings or icons to label special keys that do not
  1492. have printable characters (like tab, return, F1-F15, home, arrow keys) and
  1493. you can use KeyTrans for the other keys.
  1494.  
  1495. If, in addition to this, you show the user a picture of the keyboard he/she
  1496. is typing on with the keys clearly shown, you should be able to avoid all
  1497. confusion. (But then you have to remember that there can be multiple different
  1498. keyboards attached.)
  1499.  
  1500. -- 
  1501. Juri Munkki jmunkki@iki.fi      In cyberspace everyone can hear you scream.
  1502. http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.
  1503.  
  1504. +++++++++++++++++++++++++++
  1505.  
  1506. >From jmunkki@gamma.hut.fi (Juri Munkki)
  1507. Date: 5 Dec 1995 21:25:09 GMT
  1508. Organization: Helsinki University of Technology
  1509.  
  1510. In article <johnb-0512951811570001@slip202.hk.super.net> johnb@hk.super.net (John W. Blackburne) writes:
  1511. >First is that one problem with events is as far as I can tell you won't
  1512. >receive notification of a user pressing a modifier key. With most
  1513. >keyboards having dozens of other keys to choose from this would not be
  1514. >important, except Apple only guarantees that at at most 2 non-modifier
  1515. >keys will be properly sensed at once. Modern action games can easily have
  1516. >four or five keys in use at once, so function most reliably using
  1517. >modifiers for many of their functions.
  1518.  
  1519. Events win over GetKeys here too. The very least you will get is a
  1520. null event with the modifier keys bitmap. If the user happened to
  1521. release or press any other keys, those events will also have modifier
  1522. key bitmaps, so you actually get the state of modifier keys whenever
  1523. something else happens on the keyboard, whereas with GetKeys, you only
  1524. get the current situation.
  1525.  
  1526. The only thing you can't (as far as I know) do with events is to detect
  1527. the right side command, shift and option (ALT) keys on the extended
  1528. keyboard. (And tell them apart from the left side.)
  1529.  
  1530. >This is assuming the 'at most 2 keys plus modifiers' limit still applies.
  1531. >I think this first appeared in Inside Macintosh IV or V, and I've not seen
  1532. >anything about it since then. We've been through a few System software and
  1533. >hardware revisions since then, so does this limit still apply ?
  1534.  
  1535. It has nothing to do with system software. It's a hardware limitation
  1536. related to the way the keyboard matrix is designed. The limitation was
  1537. slightly relaxed on some keyboards (the Apple Extended Keyboard comes
  1538. to mind but there are still severe limitations to the number of
  1539. keydowns that can be detected.
  1540.  
  1541. An easy way to find them is to open Key Caps and play with holding
  1542. multiple keys: you'll see the ones that are detected highlited.
  1543.  
  1544. The two key limitation is still the lowest common denominator, so it is
  1545. a good idea to test default key layouts on such a keyboard.
  1546.  
  1547. -- 
  1548. Juri Munkki jmunkki@iki.fi      In cyberspace everyone can hear you scream.
  1549. http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.
  1550.  
  1551. +++++++++++++++++++++++++++
  1552.  
  1553. >From gordon@micron.net (Gordon Henriksen)
  1554. Date: 6 Dec 1995 00:38:10 GMT
  1555. Organization: Micron Internet Services
  1556.  
  1557. Okay, it seems to me that most people have decided to go with the Event
  1558. Manager to track keys. I only have one problem with this: How does one
  1559. track modifier keys this way? Most programs don't need it, but games ARE
  1560. the exception of most every rule. Anyway....
  1561.  
  1562.                       TTFN,
  1563.                         Gordon Henriksen
  1564.                         gordon@micron.net
  1565.         __________________________________________________    
  1566.    HAL 9000:  Dave.  Put down those Windows disks, Dave.  DAVE!
  1567. __________________________________________________________________
  1568. Microsoft is prohibited from redistributing this work in any form,
  1569. in whole or in part. Copyright, Gordon Henriksen, 1995. License to
  1570. distribute this post is available to Microsoft for $150. Posting
  1571. without permission constitutes an agreement to these terms. Please
  1572. send notices of violation to gordon@micron.net and 
  1573. Postmaster@microsoft.com
  1574.  
  1575. +++++++++++++++++++++++++++
  1576.  
  1577. >From hnsngr@sirius.com (Ron Hunsinger)
  1578. Date: Tue, 05 Dec 1995 20:31:45 -0800
  1579. Organization: ErsteSoft
  1580.  
  1581. In article <jesjones-0312951724490001@blv-pm10-ip16.halcyon.com>,
  1582. jesjones@halcyon.com (Jesse Jones) wrote:
  1583.  
  1584. > In article <lewistotle-0212951402160001@emf2-212.emf.net>,
  1585. > lewistotle@emf.net (John Lewis) wrote:
  1586. > [snip]
  1587. > > I'm currently working on a project that needs to know when the user
  1588. > > releases a key as well. I started out using the event manager and watching
  1589. > > for keyUp events. (Yes I did call SetEventMask)
  1590. > > 
  1591. > > This worked fine except when I was running under the debugger. Then, for a
  1592. > > reason I still haven't figured out, I wouldn't receive keyUp events. For
  1593. > > this reason, I ended up switching to GetKeys.
  1594. > [snip]
  1595. > For some reason the system event mask isn't reset when apps are switched
  1596. > out and in. You need to reset the mask when your app is switched in and
  1597. > change it back to the default before quitting.
  1598.  
  1599. Not so. The system event mask is maintained separately for each process,
  1600. and is switched properly whenever there is a process switch. You can set
  1601. it once during initialization and forget about it. Your setting is in
  1602. effect whenever (and only when) your application is the front process.
  1603.  
  1604. The only thing you have to worry about is keystrokes that are sent to
  1605. another process while you're in the background. To compensate, you need to
  1606. adjust your private key map each time you get a resume event. You can
  1607. either rebuild it using GetKeys (being careful to handle foreign keyboards
  1608. properly), or just flush all keyboard events and presume that all the keys
  1609. are up.
  1610.  
  1611. This came up once before in another conference, and I conducted a lengthy
  1612. conversation with the person who reported (as you did) that it doesn't
  1613. work. We finally pinned it down to his debugger. I was using MacsBug,
  1614. which shows what's actually going on. He was using the debugger integrated
  1615. into his development system (Symantec C, IIRC).
  1616.  
  1617. The problem boils down to the fact that, while you are debugging with a
  1618. high level debugger, your active process is actually the debugger rather
  1619. than the program under test, so PostEvent uses the SysEvtMask for the
  1620. debugger instead of the one set by SetEventMask in the application. To add
  1621. to the confusion, if you ask the debugger to display (or set) low memory,
  1622. it may show you the application's low memory instead of its own.
  1623.  
  1624. He found a workaround. I'm not 100% sure what it was, but I presume it was
  1625. to set SysEvtMask (at address $0144) for the debugger as well as for the
  1626. application. It's also possible that he got around the problem by
  1627. debugging with MacsBug instead of the integrated debugger. Kind of a
  1628. nuisance, I suppose, but your customers aren't going to be debugging the
  1629. final product, so it's only a nuisance to you, not them.
  1630.  
  1631. -Ron Hunsinger
  1632.  
  1633. +++++++++++++++++++++++++++
  1634.  
  1635. >From jmunkki@gamma.hut.fi (Juri Munkki)
  1636. Date: 6 Dec 1995 09:17:15 GMT
  1637. Organization: Helsinki University of Technology
  1638.  
  1639. In article <gordon-0512951741350001@cs001p06.ket.micron.net> gordon@micron.net (Gordon Henriksen) writes:
  1640. >Okay, it seems to me that most people have decided to go with the Event
  1641. >Manager to track keys. I only have one problem with this: How does one
  1642. >track modifier keys this way? Most programs don't need it, but games ARE
  1643. >the exception of most every rule. Anyway....
  1644.  
  1645. The event record has the modifiers field that you can use. That's easy
  1646. enough. The tricky thing is to detect dead keys. I forgot all about that
  1647. until I tried to use a dead key in my app...it only worked every second
  1648. time, since the first time was "dead".
  1649.  
  1650. Any suggestions as to how to handle dead keys without GetKeys or
  1651. an equivalent would be welcome. In my case, I would also prefer to
  1652. be able to use the dead keys to accent marks while the game is running,
  1653. so making them act like regular keys would not be the perfect solution.
  1654.  
  1655. It's back to the drawing board for me... ouch.
  1656.  
  1657. -- 
  1658. Juri Munkki jmunkki@iki.fi      In cyberspace everyone can hear you scream.
  1659. http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.
  1660.  
  1661. +++++++++++++++++++++++++++
  1662.  
  1663. >From reed@medicine.wustl.edu (Thomas Reed)
  1664. Date: Wed, 06 Dec 1995 09:44:19 -0600
  1665. Organization: Washington University
  1666.  
  1667. >First is that one problem with events is as far as I can tell you won't
  1668. >receive notification of a user pressing a modifier key.
  1669.  
  1670. Yeah, but every event has got bits telling what modifiers were down at the
  1671. time.  You can always do something like scan for nullEvents and check the
  1672. modifiers in the event.  The system always has nullEvents to spare, so
  1673. you'll never go looking for one and come up dry...
  1674.  
  1675. -Thomas
  1676.  
  1677. =====================================================
  1678. Thomas Reed                     Washington University
  1679. reed@visar.wustl.edu               Medical School
  1680. reed@medicine.wustl.edu            Saint Louis, MO
  1681. http://medinfo.wustl.edu/~reed
  1682. - ---------------------------------------------------
  1683. Clothes make the man.  Naked people have little or no
  1684. influence on society.  -- Mark Twain
  1685. =====================================================
  1686.  
  1687. Opinions posted are not the opinions of Wash. U.
  1688.  
  1689. +++++++++++++++++++++++++++
  1690.  
  1691. >From Frank Kane <fkane@tiac.net>
  1692. Date: Wed, 06 Dec 1995 19:30:50 -0500
  1693. Organization: Cerberus Development
  1694.  
  1695. Juri Munkki wrote:
  1696.  
  1697. > The event record has the modifiers field that you can use. That's easy
  1698. > enough. The tricky thing is to detect dead keys. I forgot all about that
  1699. > until I tried to use a dead key in my app...it only worked every second
  1700. > time, since the first time was "dead".
  1701.  
  1702. I'm not 100% sure what you mean by a "dead key."  Could you explain the problem 
  1703. you're having a bit more?   Are we talking about a bit too much dried coffee 
  1704. sitting in a contact for a key, or some quirky event manager thing related to 
  1705. handling more than two non-modifier keys being depressed simultaneously?
  1706.  
  1707. This makes me think:
  1708.  
  1709. If a user depresses and holds 'A', 'S' and 'D', in that order, I expect that 
  1710. we'll get KeyDowns for A and S but not D.  Now, if the user releases these keys 
  1711. in the opposite order, do we get a KeyUp for D with no matching KeyDown?
  1712.  
  1713. -Frank
  1714.  
  1715. +++++++++++++++++++++++++++
  1716.  
  1717. >From hnsngr@sirius.com (Ron Hunsinger)
  1718. Date: Thu, 07 Dec 1995 03:18:24 -0800
  1719. Organization: ErsteSoft
  1720.  
  1721. In article <johnb-0512951811570001@slip202.hk.super.net>,
  1722. johnb@hk.super.net (John W. Blackburne) wrote:
  1723.  
  1724. > Not so much a reply but a couple of observations.
  1725. > First is that one problem with events is as far as I can tell you won't
  1726. > receive notification of a user pressing a modifier key. 
  1727.  
  1728. Sure you do. You don't even have to keep track of them. The modifier keys
  1729. each have their own bit in the modifiers field of the Event Record. These
  1730. are valid for every event type, even nullEvt.
  1731.  
  1732. > With most
  1733. > keyboards having dozens of other keys to choose from this would not be
  1734. > important, except Apple only guarantees that at at most 2 non-modifier
  1735. > keys will be properly sensed at once. 
  1736.  
  1737. This is a limitation of the keyboard, not the OS. When you press the third
  1738. non-modifier key on a 'standard' Apple keyboard, the keyboard itself sends
  1739. a keyUp for the first key in response to the next poll.
  1740.  
  1741. Since it's the keyboard doing this, the limit of two non-modifier keys
  1742. applies no matter how you examine the results, whether with events or with
  1743. GetKeys.
  1744.  
  1745. The separate numeric keypad was non-standard in this regard, and would
  1746. report all the keys.
  1747.  
  1748. I'm pretty sure the extended keyboards treat the numeric keypad part the
  1749. same way. That is, it's only on the main block of keys that rollover is
  1750. limited to two keys. The definitive answer, as ever, is keyboard
  1751. dependent.
  1752.  
  1753. -Ron Hunsinger
  1754.  
  1755. +++++++++++++++++++++++++++
  1756.  
  1757. >From thebug@berlin.snafu.de (TheBug)
  1758. Date: Thu, 07 Dec 1995 14:05:46 +0100
  1759. Organization: privat
  1760.  
  1761. In article <30C635BA.203C@tiac.net>, fkane@phcteam.com wrote:
  1762.  
  1763. > I'm not 100% sure what you mean by a "dead key."  Could you explain the
  1764. problem 
  1765. > you're having a bit more?
  1766.  
  1767. Dead keys generate no KeyDown event on the first pressing down, like the
  1768. accent character key. Since these keys can be on different locations in
  1769. different quantities, depending on the language being used this is a BIG
  1770. problem.
  1771.  
  1772. > If a user depresses and holds 'A', 'S' and 'D', in that order, I expect that 
  1773. > we'll get KeyDowns for A and S but not D.  Now, if the user releases
  1774. these keys 
  1775. > in the opposite order, do we get a KeyUp for D with no matching KeyDown?
  1776.  
  1777. You will never see a KeyUp for which there was no KeyDown. What I wuld
  1778. guess in your case is that you can get an additional KeyDown for a key
  1779. that is not acutally pressed. This is due to the fact the keyboards are
  1780. arranged in matrixes. If you press three keys in a certain pattern in the
  1781. matrix you will see another key as being pressed, even though it actually
  1782. is'nt. To prevent this you would have to put diodes all over the matrix.
  1783. Due to production cost this is almost never done.
  1784.  
  1785. -- 
  1786. *******************************************************************
  1787. Guido Körber -            Programmer and hardware hacker 
  1788. thebug@berlin.snafu.de    Specialised in mistreating the ADB
  1789. fax: x49-30-773 81 36     Ask me about:
  1790.                            Flightstick Pro, Jetstick
  1791.                            MacEnjoy, MacEnjoy Style
  1792.  
  1793. Opinions expressed herein are mine unless expressly stated 
  1794. otherwise. Similarities with living or undead persons are
  1795. coincidence and not intended - really!   ;-)
  1796. Best use before: (see date printed on backside of message)
  1797. *******************************************************************
  1798.  
  1799. +++++++++++++++++++++++++++
  1800.  
  1801. >From jmunkki@gamma.hut.fi (Juri Munkki)
  1802. Date: 7 Dec 1995 21:51:05 GMT
  1803. Organization: Helsinki University of Technology
  1804.  
  1805. In article <30C635BA.203C@tiac.net> fkane@phcteam.com writes:
  1806. >Juri Munkki wrote:
  1807. >> The event record has the modifiers field that you can use. That's easy
  1808. >> enough. The tricky thing is to detect dead keys. I forgot all about that
  1809. >> until I tried to use a dead key in my app...it only worked every second
  1810. >> time, since the first time was "dead".
  1811. >
  1812. >I'm not 100% sure what you mean by a "dead key."  Could you explain the problem
  1813.  
  1814. Look up the words "dead key" in Inside Macintosh. They are usually used to
  1815. provide accented characters. When you hit the accent mark key, no keyDown
  1816. is reported. If you then hit a character that can not accept an accent,
  1817. the dead key (a backquote, for instance)  keyDown is queued as well as
  1818. the character that could not be accented.
  1819.  
  1820. There's a funny feature related to that too. The keyDown event for the
  1821. dead key receives it's modifier keys from the next key, so:
  1822.  
  1823.         if you try to enter ~ ctrl-Z to suspend an rlogin:
  1824.  
  1825.         - the ~ is a dead key (on at least some KCHRs), so it doesn't cause
  1826.           a keyDown.
  1827.         - The ctrl-Z is entered and obviously a control character can not
  1828.           take the accent, but instead of ~ctrl-Z, we actually get ctrl-~
  1829.           ctrl-Z, because the modifier keys from the ctrl-Z are copied to
  1830.           the dead key.
  1831.  
  1832. It was a major problem for me, back when I was writing a terminal program
  1833. that ran on a keyboard with no control key. The command key could be used
  1834. as the control key, so pressing ~ command-Z actually cause ctrl-~ ctrl-Z
  1835. to be sent. It doesn't have much relevance to games though.
  1836.  
  1837. >you're having a bit more?   Are we talking about a bit too much dried coffee 
  1838. >sitting in a contact for a key, or some quirky event manager thing related to 
  1839. >handling more than two non-modifier keys being depressed simultaneously?
  1840.  
  1841. I usually wash my keyboard when I spill Coca Cola on it.
  1842.  
  1843. >If a user depresses and holds 'A', 'S' and 'D', in that order, I expect that 
  1844. >we'll get KeyDowns for A and S but not D.  Now, if the user releases these keys
  1845. >in the opposite order, do we get a KeyUp for D with no matching KeyDown?
  1846.  
  1847. You can only get keyUps for keys that have gotten keyDowns. Every keyUp is
  1848. preceded by a keyDown. If you hold down 456 and then release 4, you will get
  1849. a keyUp for 4 and then immediately a keyDown for 6.
  1850.  
  1851. As I remember it, the limitations of the extended keyboard are really
  1852. funky... you can hold down certain combinations of keys, but not others.
  1853. Key Caps is again your friend in exploring these mysteries.
  1854.  
  1855. -- 
  1856. Juri Munkki jmunkki@iki.fi      In cyberspace everyone can hear you scream.
  1857. http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.
  1858.  
  1859. +++++++++++++++++++++++++++
  1860.  
  1861. >From dsemchi@glenayre.com (Dale Semchishen [4597])
  1862. Date: Wed, 6 Dec 1995 20:45:59 GMT
  1863. Organization: Glenayre Electronics Ltd.
  1864.  
  1865. In article 0512951811570001@slip202.hk.super.net, johnb@hk.super.net (John W. Blackburne) writes:
  1866. >This is assuming the 'at most 2 keys plus modifiers' limit still applies.
  1867. >I think this first appeared in Inside Macintosh IV or V, and I've not seen
  1868. >anything about it since then. We've been through a few System software and
  1869. >hardware revisions since then, so does this limit still apply ?
  1870.  
  1871. The limit on the number of simultaneous keys being held down
  1872. (and still detected) is a function of the keyboard and its driver.
  1873.  
  1874. If I connect the keyboard that came with my SE to my LCIII, I only
  1875. get 2 key rollover (regardless of the operating system version).
  1876.  
  1877. If I connect a 3rd party keyboard to my LCIII, then I get
  1878. many key rollover. I held down as many as I could at the same time
  1879. and all keys were returned by the Event Manager.
  1880.  
  1881.  
  1882.  
  1883. +++++++++++++++++++++++++++
  1884.  
  1885. >From meggs@virginia.edu (Andrew Meggs)
  1886. Date: Thu, 7 Dec 1995 23:10:22 GMT
  1887. Organization: University of Virginia
  1888.  
  1889. In article <49ufan$kgj@newsy.ifm.liu.se>, ingemar@lysator.liu.se (Ingemar
  1890. Ragnemalm) wrote:
  1891. > Also, with events you *know* what key the user has hit. With GetKeys,
  1892. > you only have the key code, you don't know what key it is. Assuming that
  1893. > the key codes are the same on all keyboards is foolish. Dark Forces
  1894. > does it, but that's no excuse. (The "+" key shinks the map and the "'"
  1895. > key expands it - not good at all!)
  1896.  
  1897. Could you perhaps fill in my knowledge of Mac key mapping a little
  1898. bit? GetKeys returns virtual key codes, not raw key codes, so presumably
  1899. they've already been mapped through the KMAP resource. Other than the
  1900. conversion to ASCII (at which point you lose the ability to distinguish
  1901. between the keypad and the numbers on the main keyboard, and other such
  1902. misfortunes), what translation is left after you've got a virtual
  1903. key code?
  1904.  
  1905. -- 
  1906. _________________________________________________________________________
  1907. andrew meggs                               the one who dies with the most
  1908. meggs@virginia.edu                              AOL free trial disks wins
  1909.  
  1910. +++++++++++++++++++++++++++
  1911.  
  1912. >From hnsngr@sirius.com (Ron Hunsinger)
  1913. Date: Fri, 08 Dec 1995 06:08:57 -0800
  1914. Organization: ErsteSoft
  1915.  
  1916. In article <30C635BA.203C@tiac.net>, fkane@phcteam.com wrote:
  1917.  
  1918. > If a user depresses and holds 'A', 'S' and 'D', in that order, I expect that 
  1919. > we'll get KeyDowns for A and S but not D.  Now, if the user releases
  1920. these keys 
  1921. > in the opposite order, do we get a KeyUp for D with no matching KeyDown?
  1922.  
  1923. Assuming that the keyboard doesn't get confused, here's what happens on a
  1924. strict 2-key-rollover keyboard:
  1925.  
  1926.   1) User presses A.  Keyboard sends keyDown(A).
  1927.  
  1928.   2) User presses S.  Keyboard sends keyDown(S).
  1929.  
  1930.   3) User presses D.  Keyboard sends keyUp(A), then keyDown(D).
  1931.  
  1932.   4) User releases A. Keyboard does nothing.
  1933.  
  1934.   5) User releases S. Keyboard sends keyUp(S).
  1935.  
  1936.   6) User releases D. Keyboard sends keyUp(D).
  1937.  
  1938. At time (3), the keyboard knows that A is still down, but sends the keyUp
  1939. for it anyway so that the computer will not 'see' more than two
  1940. non-modifier keys down. Not all keyboards will do this, because not all
  1941. keyboards are afraid to show more than two keys down.
  1942.  
  1943. By "assuming that the keyboard doesn't get confuse", I'm referring to the
  1944. fact that on many (most) keyboards, there are combinations of three keys,
  1945. on three corners of a rectangle on the scanning grid, that will make the
  1946. keyboard mistakenly think the key on the fourth corner is also pressed.
  1947.  
  1948. My Apple Extended Keyboard (M3501) is happy to show "asdfhjcb," all at the
  1949. same time (at which time I run out of fingers). It will not, however, show
  1950. "afg" at the same time. In this sense, the limit seems to be that the
  1951. keyboard only promises to faithfully report both of any two keys pressed.
  1952. It makes no guarantee about what happens when more keys are pressed.
  1953.  
  1954. The effect may in some cases be timing related. For example, if I press
  1955. and hold "o" and then press "u" and "t" simultaneously, I may get "ot", or
  1956. "ou", or "ou;". This has in fact been reported by several users: if you
  1957. type "out" very quickly, you may get "ou;".
  1958.  
  1959. Try playing with KeyCaps to see what you get on your keyboard. Ignore any
  1960. auto-repeat, which is generated by the event manager and not by the
  1961. keyboard. Keep in mind that not all your customers will have your
  1962. keyboard.
  1963.  
  1964. -Ron Hunsinger
  1965.  
  1966. +++++++++++++++++++++++++++
  1967.  
  1968. >From gordon@micron.net (Gordon Henriksen)
  1969. Date: 9 Dec 1995 02:45:34 GMT
  1970. Organization: Micron Internet Services
  1971.  
  1972. In article <30C635BA.203C@tiac.net>, fkane@phcteam.com wrote:
  1973.  
  1974. > Juri Munkki wrote:
  1975. > > The event record has the modifiers field that you can use. That's easy
  1976. > > enough. The tricky thing is to detect dead keys. I forgot all about that
  1977. > > until I tried to use a dead key in my app...it only worked every second
  1978. > > time, since the first time was "dead".
  1979.  
  1980. > I'm not 100% sure what you mean by a "dead key."  Could you explain the
  1981. > problem you're having a bit more?   Are we talking about a bit too much dried 
  1982. > coffee sitting in a contact for a key, or some quirky event manager thing 
  1983. > related to handling more than two non-modifier keys being depressed 
  1984. > simultaneously?
  1985.  
  1986. Fire up your favorite text/word processor. Type option-n. NOTHING happens.
  1987. Now type a vowel. The vowel should appear with an accent mark that looks
  1988. like a tilide (~) over it. The point of this is to extend the keyboard in
  1989. such a way as to be able to type accent marks and have the keystrokes
  1990. involved be somewhat intuitive. It is much easier than having to remember
  1991. a specific keystroke for each letter's accent mark. The technique [sp?]
  1992. also works on capitals just as would be expected. The reason the program
  1993. didn't respond was because it simply wasn't notified of the stroke. The
  1994. System obviously stores them in some internal variable, and there is no
  1995. way that I am aware of to work around them using events.
  1996.  
  1997. > This makes me think:
  1998.  
  1999. > If a user depresses and holds 'A', 'S' and 'D', in that order, I expect that 
  2000. > we'll get KeyDowns for A and S but not D.  Now, if the user releases these 
  2001. > keys in the opposite order, do we get a KeyUp for D with no matching KeyDown?
  2002.  
  2003. No. Allow me to illustrate:
  2004.  
  2005.  User | Computer
  2006. - ----+----------
  2007.  A    |   A      
  2008.  AS   |   AS     
  2009.  ASD  |   AS     //  'd' depressed, but the keyboard doesn't see it
  2010.  AS   |   AS     //  'd' released, but since the keyboard didn't see it, it
  2011.       |          //     doesn't respond
  2012.  A    |   A      
  2013.  
  2014. Since the keyboard usually can only detect two keys at a time, the 'd'
  2015. wouldn't be registered at all. If we performed a similar operation as
  2016. follows, I think that a 'd' KeyUp event would be registered without a
  2017. corresponding KeyDown. On the other hand, it could result in a KeyUp as
  2018. soon as the 'a' key is released.
  2019.  
  2020.  User | Computer 
  2021. - ----+----------
  2022.  A    |  A        
  2023.  AS   |  AS       
  2024.  ASD  |  AS      //  'd' is also depressed, but the keyboard doesn't see it
  2025.   SD  |   SD     //  now it sees it. Does it generate a KeyUp or nothing?
  2026.    D  |    D      
  2027.  
  2028. Anyone care to tell us what would really happen? I find this discussion
  2029. fascinating because I was not actively aware of this limitation to the
  2030. standard keyboard.
  2031.  
  2032.                       TTFN,
  2033.                         Gordon Henriksen
  2034.                         gordon@micron.net
  2035.         __________________________________________________    
  2036.    HAL 9000:  Dave.  Put down those Windows disks, Dave.  DAVE!
  2037. __________________________________________________________________
  2038. Microsoft is prohibited from redistributing this work in any form,
  2039. in whole or in part. Copyright, Gordon Henriksen, 1995. License to
  2040. distribute this post is available to Microsoft for $150. Posting
  2041. without permission constitutes an agreement to these terms. Please
  2042. send notices of violation to gordon@micron.net and 
  2043. Postmaster@microsoft.com
  2044.  
  2045. +++++++++++++++++++++++++++
  2046.  
  2047. >From albtrssp@crocker.com (Kevin Tieskoetter)
  2048. Date: 7 Dec 1995 21:27:13 GMT
  2049. Organization: Albatross Productions
  2050.  
  2051. In article <reed-0612950944190001@thomasmac.wustl.edu>
  2052. reed@medicine.wustl.edu (Thomas Reed) writes:
  2053.  
  2054. > >First is that one problem with events is as far as I can tell you won't
  2055. > >receive notification of a user pressing a modifier key.
  2056. > Yeah, but every event has got bits telling what modifiers were down at the
  2057. > time.  You can always do something like scan for nullEvents and check the
  2058. > modifiers in the event.  The system always has nullEvents to spare, so
  2059. > you'll never go looking for one and come up dry...
  2060.  
  2061. That doesn't seem to make much sense - why deliberately look for a null
  2062. event just so you can see what modifiers were being held down when that
  2063. null event took place? (is the modifier field even valid for null
  2064. events?) If you always know you're going to get a null event (I'm not
  2065. sure this is true), why not just call GetKeys() instead?
  2066.  
  2067. -kevin
  2068.  
  2069. //---------------------------------------------------------------------
  2070.    Kevin Tieskoetter / Software Prestidigitator, Specular International
  2071. //---------------------------------------------------------------------
  2072.  
  2073. +++++++++++++++++++++++++++
  2074.  
  2075. >From albtrssp@crocker.com (Kevin Tieskoetter)
  2076. Date: 7 Dec 1995 21:29:32 GMT
  2077. Organization: Albatross Productions
  2078.  
  2079. In article <gordon-0512951741350001@cs001p06.ket.micron.net>
  2080. gordon@micron.net (Gordon Henriksen) writes:
  2081.  
  2082. > Okay, it seems to me that most people have decided to go with the Event
  2083. > Manager to track keys. I only have one problem with this: How does one
  2084. > track modifier keys this way? Most programs don't need it, but games ARE
  2085. > the exception of most every rule. Anyway....
  2086.  
  2087. What I do is call WaitNextEvent every 5 ticks or so, then call
  2088. GetKeys() every other time. I can track modifier keys through
  2089. GetKeys(), plus the rest of the system gets time to work. There's not
  2090. much point in calling WaitNextEvent() several times a second, which is
  2091. what many programs end up doing since they made assumptions about the
  2092. processor speed which weren't true...
  2093.  
  2094. -kevin
  2095.  
  2096. //---------------------------------------------------------------------
  2097.    Kevin Tieskoetter / Software Prestidigitator, Specular International
  2098. //---------------------------------------------------------------------
  2099.  
  2100. +++++++++++++++++++++++++++
  2101.  
  2102. >From thebug@berlin.snafu.de (TheBug)
  2103. Date: Thu, 07 Dec 1995 14:05:46 +0100
  2104. Organization: privat
  2105.  
  2106. In article <30C635BA.203C@tiac.net>, fkane@phcteam.com wrote:
  2107.  
  2108. > I'm not 100% sure what you mean by a "dead key."  Could you explain the
  2109. problem 
  2110. > you're having a bit more?
  2111.  
  2112. Dead keys generate no KeyDown event on the first pressing down, like the
  2113. accent character key. Since these keys can be on different locations in
  2114. different quantities, depending on the language being used this is a BIG
  2115. problem.
  2116.  
  2117. > If a user depresses and holds 'A', 'S' and 'D', in that order, I expect that 
  2118. > we'll get KeyDowns for A and S but not D.  Now, if the user releases
  2119. these keys 
  2120. > in the opposite order, do we get a KeyUp for D with no matching KeyDown?
  2121.  
  2122. You will never see a KeyUp for which there was no KeyDown. What I wuld
  2123. guess in your case is that you can get an additional KeyDown for a key
  2124. that is not acutally pressed. This is due to the fact the keyboards are
  2125. arranged in matrixes. If you press three keys in a certain pattern in the
  2126. matrix you will see another key as being pressed, even though it actually
  2127. is'nt. To prevent this you would have to put diodes all over the matrix.
  2128. Due to production cost this is almost never done.
  2129.  
  2130. -- 
  2131. *******************************************************************
  2132. Guido Körber -            Programmer and hardware hacker 
  2133. thebug@berlin.snafu.de    Specialised in mistreating the ADB
  2134. fax: x49-30-773 81 36     Ask me about:
  2135.                            Flightstick Pro, Jetstick
  2136.                            MacEnjoy, MacEnjoy Style
  2137.  
  2138. Opinions expressed herein are mine unless expressly stated 
  2139. otherwise. Similarities with living or undead persons are
  2140. coincidence and not intended - really!   ;-)
  2141. Best use before: (see date printed on backside of message)
  2142. *******************************************************************
  2143.  
  2144. ---------------------------
  2145.  
  2146. >From timmyd@netcom.com (Tim DeBenedictis)
  2147. Subject: How do I draw dashed lines?
  2148. Date: Thu, 7 Dec 1995 07:36:50 GMT
  2149. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  2150.  
  2151. In Windows GDI, there is an option to create a "dashed" pen, and anything 
  2152. you draw with that pen will have a dashed-line appearance (squares, 
  2153. circles, etc.)  Does Mac QuickDraw have anything similar?  I know you 
  2154. could always just set the PenPat, but that's not what I'm looking for: I 
  2155. want an honest-to-god, genuine dashed-line pen.  Am I going to have to 
  2156. write my own DrawDashedLine() routine (which, I assume, would consist of 
  2157. a bunch of LineTo()/MoveTo() calls)?  If so, can anybpdy present me with 
  2158. a simple algorithm, or better yet sample code?
  2159.  
  2160. Thanks!
  2161.  
  2162. -Tim DeBenedictis
  2163. timmyd@netcom.com
  2164.  
  2165.  
  2166. +++++++++++++++++++++++++++
  2167.  
  2168. >From vision@cc.swarthmore.edu (Frank Durgin, Stephen Sample, and various student researchers)
  2169. Date: Mon, 11 Dec 1995 09:06:41 -0500
  2170. Organization: Swarthmore Visual Perception Lab
  2171.  
  2172. In article <timmydDJ7H5E.HEC@netcom.com>, timmyd@netcom.com (Tim
  2173. DeBenedictis) wrote:
  2174.  
  2175. > In Windows GDI, there is an option to create a "dashed" pen, and anything 
  2176. > you draw with that pen will have a dashed-line appearance (squares, 
  2177. > circles, etc.)  Does Mac QuickDraw have anything similar?  I know you 
  2178. > could always just set the PenPat, but that's not what I'm looking for: I 
  2179. > want an honest-to-god, genuine dashed-line pen.
  2180.  
  2181. Well, GX supports dashed pens (with arbitrary dash shapes yet!) so you
  2182. could use that. It would give you lots of other really cool graphics
  2183. features more or less for free, too, but, OTOH, you'd have to require GX
  2184. (or Copland).
  2185.  
  2186.  
  2187. Ta,
  2188.    -Stephen
  2189.  
  2190. -- 
  2191. Frank Durgin, Stephen Sample, & various student researchers
  2192. - --------------------------
  2193. Visual Perception Laboratory
  2194. Department of Psychology
  2195. Swarthmore College
  2196.  
  2197. ---------------------------
  2198.  
  2199. >From Frank Kane <fkane@tiac.net>
  2200. Subject: Network code on a PPC native project?
  2201. Date: Sun, 03 Dec 1995 09:44:06 +0000
  2202. Organization: Cerberus Development
  2203.  
  2204. Just got my copy of Tricks of the Mac Game Programming Gurus, began 
  2205. reading the chapter on networking, got all inspired, and decided I'd 
  2206. add network play to my current project.
  2207.  
  2208. But then you get to a little aside that says "oh by the way, you 
  2209. need to use 68K assembly for the callback routines, if you're making 
  2210. a PowerPC native game, sorry, thanks for playing.  It's possible, 
  2211. but good luck."  Well, not in those words exactly.
  2212.  
  2213. Now, I know it's possible to get the Mixed Mode Manager to use 68K 
  2214. code from a PowerPC app, via UPP's or something.  Personally, I have 
  2215. no clue how UPP's work unless they're set up for me in a header 
  2216. file.
  2217.  
  2218. Does anybody have any experience in handling networks from a PPC 
  2219. native app?  How do you use the 68K assembly from a PPC project?  
  2220. (Besides trying to use the new Open Transport calls instead) Do I 
  2221. need to somehow get the 68K code in a resource or something?  
  2222.  
  2223. Thanks!
  2224. -Frank
  2225.  
  2226. +++++++++++++++++++++++++++
  2227.  
  2228. >From ajbarry@ozemail.com.au (Andrew Barry)
  2229. Date: Thu, 07 Dec 1995 14:53:48 +1000
  2230. Organization: Interconnect Australia
  2231.  
  2232. > Does anybody have any experience in handling networks from a PPC 
  2233. > native app?  How do you use the 68K assembly from a PPC project?  
  2234. > (Besides trying to use the new Open Transport calls instead) Do I 
  2235. > need to somehow get the 68K code in a resource or something?  
  2236.  
  2237. Ran into exactly this problem when doing the PowerPC version of 'Prince of
  2238. Destruction' - my DDP socket listener was written as a code resource,
  2239. which I then loaded and created a UPP to it.
  2240.  
  2241. If you look in AppleTalk.h, you'll notice upp info definitions for the
  2242. various procs. eg. uppDDPSocketListenerProcInfo
  2243.  
  2244. ---------------------------
  2245.  
  2246. >From vanessa@io.org (Vanessa Williams)
  2247. Subject: Spheres in Q3D?
  2248. Date: Sat, 09 Dec 1995 22:00:40 -0500
  2249. Organization: Tessera Solutions
  2250.  
  2251. Anyone have any ideas on the best way to render spheres, cylinders etc. in
  2252. QuickDraw 3D? I'm assuming NURB surfaces are the way to go, but don't know
  2253. exactly how to specify basic surfaces using NURBS. All of the info I have
  2254. on NURBS is very theoretical, no practical examples to speak of (i.e.
  2255. Foley and Van Dam). Any ideas or pointers appreciated.
  2256.  
  2257. Thanks,
  2258.  
  2259. Vanessa
  2260.  
  2261. -- 
  2262. Vanessa Williams
  2263. Tessera Solutions, Interactive Graphics & Multimedia
  2264. vanessa@io.org
  2265. http://www.io.org/~vanessa/
  2266.  
  2267. +++++++++++++++++++++++++++
  2268.  
  2269. >From ashearer@mail.rihosp.edu (Andrew Shearer)
  2270. Date: Mon, 11 Dec 1995 20:50:18 -0500
  2271. Organization: Rhode Island Hospital
  2272.  
  2273. In article <vanessa-0912952200400001@ts7-15.inforamp.net>, vanessa@io.org
  2274. (Vanessa Williams) wrote:
  2275.  
  2276. >Anyone have any ideas on the best way to render spheres, cylinders etc. in
  2277. >QuickDraw 3D? I'm assuming NURB surfaces are the way to go, but don't know
  2278. >exactly how to specify basic surfaces using NURBS. All of the info I have
  2279. >on NURBS is very theoretical, no practical examples to speak of (i.e.
  2280. >Foley and Van Dam). Any ideas or pointers appreciated.
  2281.  
  2282. One of the pieces of QD3D sample code (TriGrids?) has a sphere creation
  2283. routine. It doesn't add vertex normals, though, so the sphere looks
  2284. faceted even with vertex interpolation on. 
  2285.  
  2286. Here's a version modified to add normals. (I removed some extra code
  2287. before posting; hopefully, I didn't break anything.) 1.5 is a good value
  2288. for inQuality. CheckQ3Object() and CheckQ3Status() are error-checking
  2289. routines.
  2290.  
  2291. TQ3GeometryObject
  2292. MakeSphere(
  2293.    float inRadius,
  2294.    float inQuality)
  2295. {
  2296.    /*
  2297.     * vvValue is an angle used to generate each half circular cross section
  2298.     * uuValue is an angle used to revolve the cross section about the y axis
  2299.     */
  2300.    const float vvMin = -kQ3PiOver2, vvMax = kQ3PiOver2;
  2301.    const float uuMin = 0.0, uuMax = kQ32Pi;
  2302.    const unsigned long theNumRows = (6 * inQuality)  + 1, theNumColumns =
  2303. (10 * inQuality) + 1;
  2304.  
  2305.    StPointerBlock theVerticesPtr(theNumRows * theNumColumns *
  2306. sizeof(TQ3Vertex3D));
  2307.    TQ3Vertex3D *theVertices = (TQ3Vertex3D*) Ptr(theVerticesPtr);
  2308.    // Non-PowerPlant C version:
  2309.    // TQ3Vertex3D *theVertices = (TQ3Vertex3D *) ::NewPtr (theNumRows *
  2310. theNumColumns * sizeof(TQ3Vertex3D));
  2311.    // ThrowIfMemFail_(theVertices);
  2312.    
  2313.    const float uuStep = (uuMax - uuMin) / (theNumColumns - 1);
  2314.    const float vvStep = (vvMax - vvMin) / (theNumRows - 1);
  2315.    
  2316.    for (unsigned long theRow = 0; theRow < theNumRows; theRow++) {
  2317.       for (unsigned long theColumn = 0; theColumn < theNumColumns;
  2318. theColumn++) {
  2319.          const float uuRadians = uuMax - theColumn * uuStep;
  2320.          const float vvRadians = vvMin + theRow * vvStep;
  2321.          TQ3Vertex3D &theVertex = theVertices[theColumn + theRow *
  2322. theNumColumns];
  2323.          const TQ3Vector3D theNormal =
  2324.             {cos(vvRadians) * cos(uuRadians), sin(vvRadians),
  2325. cos(vvRadians) * sin(uuRadians)};
  2326.          
  2327.          theVertex.point.x = inRadius * theNormal.x;
  2328.          theVertex.point.y = inRadius * theNormal.y;
  2329.          theVertex.point.z = inRadius * theNormal.z;
  2330.          theVertex.attributeSet = CheckQ3Object(Q3AttributeSet_New());
  2331.          CheckQ3Status(Q3AttributeSet_Add(theVertex.attributeSet,
  2332. kQ3AttributeTypeNormal, &theNormal));
  2333.       }
  2334.    }
  2335.    
  2336.    const TQ3TriGridData data =
  2337.       {theNumRows, theNumColumns, theVertices, nil /*facetAttributeSet*/,
  2338. nil /*triGridAttributeSet*/};
  2339.    TQ3GeometryObject outResult = Q3TriGrid_New(&data);
  2340.  
  2341.   for (long i = 0; i < theNumRows * theNumColumns; i++) {
  2342.       CheckQ3Status(Q3Object_Dispose(theVertices[i].attributeSet));
  2343.    }
  2344.  
  2345.    // C version:
  2346.    //::DisposePtr((Ptr)theVertices);
  2347.    
  2348.     return CheckQ3Object(outResult);
  2349. }
  2350.  
  2351. -- 
  2352. Andrew Shearer
  2353. Regular email: ashearer@mail.rihosp.edu
  2354. (may be changing to ashearer@rihosp.edu)
  2355.  
  2356. ---------------------------
  2357.  
  2358. >From dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way)
  2359. Subject: WaitNextEvent & Background Processing
  2360. Date: 6 Dec 1995 20:48:56 GMT
  2361. Organization: ECC at Ford Motor Company, Dearborn Michigan
  2362.  
  2363. Juri Munkki (jmunkki@gamma.hut.fi) wrote:
  2364. > In article <49ufan$kgj@newsy.ifm.liu.se> ingemar@lysator.liu.se (Ingemar
  2365. Ragnemalm) writes:
  2366. > >It makes a big difference if you use WNE with a sleep time > 0, or have
  2367. > >lots of applications in the background.
  2368. >
  2369. > During games, I never call WNE. I may call GetNextEvent, if the user
  2370. > has background processing enabled, but the best thing is usually to
  2371. > call only GetOSEvent, since it doesn't allow any background processing.
  2372.  
  2373. (I wanted to start a new thread on this, since I had some questions about
  2374. WaitNextEvent.)
  2375.  
  2376. I'm writing a game in which I'm NOT calling WaitNextEvent (or anything 
  2377. similar) unless the user decides to enable "background processing" in a 
  2378. preferences dialog.  My initial impression was that if I didn't call 
  2379. WaitNextEvent, I wouldn't have to worry about background processes taking up 
  2380. valuable CPU time.
  2381.  
  2382. However, when I was testing the frame rate, I noticed a weird thing.  If I had 
  2383. extensions turned off, the frame rate was around 360 frames/sec.  If I turned 
  2384. extensions on, the frame rate was about 270 frames/sec.  (You're probably 
  2385. thinking that's damn fast anyway, but this is on a 7200/90 and I still have to 
  2386. add a lot more complexity to the game.)  It turned out that the main culprit 
  2387. was AfterDark (2.0).  If I removed AfterDark, the frame rate was about the 
  2388. same whether other extensions were on or off.
  2389.  
  2390. So I'm wondering, are there certain kinds of background processes that can 
  2391. occur whether or not I'm calling WaitNextEvent?  (I'm sure the After Dark 
  2392. thing is not a RAM issue, the System and the game each take up about 5 megs on 
  2393. my 16 meg machine... also, I'm wondering why AfterDark would need to chew up 
  2394. so many resources just checking for inactivity.)  Or, could it be that some 
  2395. other toolbox routine I'm calling somehow allows for event processing?  I 
  2396. thought only WaitNextEvent and GetNextEvent did this.  To be fair, I do use 
  2397. WaitNextEvent for the menu interface (for starting a new game, etc), but this 
  2398. is outside of the game loop where I'm testing the frame rates.
  2399.  
  2400. (Also, I'm curious as to why Juri calls GetNextEvent rather than 
  2401. WaitNextEvent.  Is it more efficient?)
  2402.  
  2403. Any ideas?  (Please post rather than emailing me.)
  2404.  
  2405. - Doug Way
  2406.   deway@umich.edu
  2407.   Bebound!
  2408.  
  2409.  
  2410. +++++++++++++++++++++++++++
  2411.  
  2412. >From Frank Kane <fkane@tiac.net>
  2413. Date: Wed, 06 Dec 1995 19:07:43 -0500
  2414. Organization: Cerberus Development
  2415.  
  2416. Douglas E. Way wrote:
  2417.  
  2418. > However, when I was testing the frame rate, I noticed a weird thing.  If I had
  2419. > extensions turned off, the frame rate was around 360 frames/sec.  If I turned
  2420. > extensions on, the frame rate was about 270 frames/sec.  (You're probably
  2421. > thinking that's damn fast anyway, but this is on a 7200/90 and I still have to
  2422. > add a lot more complexity to the game.)  It turned out that the main culprit
  2423. > was AfterDark (2.0).  If I removed AfterDark, the frame rate was about the
  2424. > same whether other extensions were on or off.
  2425.  
  2426. I'm no expert on how After Dark works (or on much else for that matter,) but I do 
  2427. know that neglecting WaitNextEvent will do nothing to stop tasks that run on 
  2428. interrupts.  File Sharing is a good example, and it's probably a good bet that 
  2429. After Dark does too.  I'm probably oversimplifying, but apps like this will eat 
  2430. up CPU time whenever the screen gets redrawn (every 1/60 second) whether or not 
  2431. you give them time with WaitNextEvent.
  2432.  
  2433. If speed is critical, it's usually a good idea to give the user the option to 
  2434. kill file sharing and the finder when starting up your game.  There's some code 
  2435. to do this available at ftp.info.apple.com if you hunt long enough (look for a 
  2436. game folder, it's in there.)
  2437.  
  2438. Hope this helps somewhat...
  2439.  
  2440. -Frank
  2441.  
  2442. +++++++++++++++++++++++++++
  2443.  
  2444. >From jregier@qualcomm.com (Jason Regier)
  2445. Date: Wed, 06 Dec 1995 17:14:11 -0800
  2446. Organization: Qualcomm, Inc.
  2447.  
  2448. Regarding slowdowns with After Dark installed:
  2449. > I'm no expert on how After Dark works (or on much else for that matter,)
  2450. but I > do know that neglecting WaitNextEvent will do nothing to stop
  2451. tasks that run 
  2452. > on interrupts.  I'm probably oversimplifying, but apps like this will eat 
  2453. > up CPU time whenever the screen gets redrawn (every 1/60 second) whether or 
  2454. > not you give them time with WaitNextEvent.
  2455. AfterDark most likely has to install some periodic interrupt (it doesn't
  2456. necessarily have to be tied to the 60 Hz vertical retrace clock) in order
  2457. to turn on when your mouse is placed in the corner.  When the interrupt
  2458. executes, it takes over the processor (thus stalling your application),
  2459. checks the mouse position, and relinquishes control of the processor back
  2460. to your app.  You most likely notice the lag incurred by checking the
  2461. mouse position and switching contexts between your app and AfterDark. 
  2462.  
  2463. Assuming this is the case, kill AfterDark, and your problem will go away,
  2464. just as you found.
  2465.  
  2466. Jason
  2467.  
  2468. -- 
  2469. Jason Regier
  2470. GlobalStar Software Engineer
  2471. QUALCOMM, Inc.
  2472. (619) 658-4752
  2473. jregier@qualcomm.com
  2474.  
  2475. +++++++++++++++++++++++++++
  2476.  
  2477. >From erichsen@pacificnet.net (Erichsen)
  2478. Date: 7 Dec 1995 04:21:40 GMT
  2479. Organization: Disorganized
  2480.  
  2481. In article <4a4vjo$cbl@eccdb1.pms.ford.com>,
  2482. dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way) wrote:
  2483.  
  2484.  
  2485. >However, when I was testing the frame rate, I noticed a weird thing.  If I had 
  2486. >extensions turned off, the frame rate was around 360 frames/sec.  If I turned 
  2487. >extensions on, the frame rate was about 270 frames/sec.  (You're probably 
  2488. >thinking that's damn fast anyway, but this is on a 7200/90 and I still have to 
  2489. >add a lot more complexity to the game.)  It turned out that the main culprit 
  2490. >was AfterDark (2.0).  If I removed AfterDark, the frame rate was about the 
  2491. >same whether other extensions were on or off.
  2492.  
  2493. The slowdown has nothing to do with background processing, it's extensions
  2494. patching traps. After Dark does this like it's going out of style. I'm not
  2495. sure if they've fixed it yet or not but, a lot of the stuff it patches is
  2496. replaced with 680x0 code which may be fine on a 680x0 machine but, on a
  2497. PowerPC if they patch something that is native, it's going to run emulated
  2498. and really slow you down.
  2499.  
  2500. You should try doing everything correctly (ie. calling WaitNextEvent and
  2501. processing events) and see what kind of speed you get. If you're not
  2502. getting the speed you want, try to improve your algorithms and as a VERY
  2503. last resort, limit your calls to WaitNextEvent. Don't just stop calling
  2504. it, throttle it so you can adjust how often it's called and decrease this
  2505. until you get the speed you need.
  2506.  
  2507. +++++++++++++++++++++++++++
  2508.  
  2509. >From jmunkki@gamma.hut.fi (Juri Munkki)
  2510. Date: 7 Dec 1995 10:57:29 GMT
  2511. Organization: Helsinki University of Technology
  2512.  
  2513. In article <4a4vjo$cbl@eccdb1.pms.ford.com> dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way) writes:
  2514. >I'm writing a game in which I'm NOT calling WaitNextEvent (or anything 
  2515. >However, when I was testing the frame rate, I noticed a weird thing.  If I had 
  2516. >extensions turned off, the frame rate was around 360 frames/sec.  If I turned 
  2517. >extensions on, the frame rate was about 270 frames/sec.  (You're probably 
  2518. >thinking that's damn fast anyway, but this is on a 7200/90 and I still have to 
  2519. >add a lot more complexity to the game.)  It turned out that the main culprit 
  2520. >was AfterDark (2.0).  If I removed AfterDark, the frame rate was about the 
  2521. >same whether other extensions were on or off.
  2522.  
  2523. It needs to monitor what is happening on the machine, so I guess it patches
  2524. here and there and since it's probably not a fat extension, the patches
  2525. make the PPC emulate 68K code and thus slow it down (cache deteriorates
  2526. fast with 68K emulation).
  2527.  
  2528. It could also be installing time manager tasks for some reason.
  2529.  
  2530. >other toolbox routine I'm calling somehow allows for event processing?  I 
  2531. >thought only WaitNextEvent and GetNextEvent did this.  To be fair, I do use 
  2532. >WaitNextEvent for the menu interface (for starting a new game, etc), but this 
  2533. >is outside of the game loop where I'm testing the frame rates.
  2534.  
  2535. The best you can do is call GetOSEvent. The rest is left up the the
  2536. users. Try to warn them that the game will run faster without extensions.
  2537. Then again, everything runs faster without extensions, so they might
  2538. already know.
  2539.  
  2540. Debuggers also tend to slow down the machine.
  2541.  
  2542. >(Also, I'm curious as to why Juri calls GetNextEvent rather than 
  2543. >WaitNextEvent.  Is it more efficient?)
  2544.  
  2545. Just old habit. The main application calls WaitNextEvent, but GetNextEvent
  2546. is a bit simpler and does the same thing. It probably gets translated into
  2547. a WaitNextEvent. It shouldn't matter unless you want to be compatible with
  2548. historical Macs.
  2549.  
  2550. -- 
  2551. Juri Munkki jmunkki@iki.fi      In cyberspace everyone can hear you scream.
  2552. http://www.iki.fi/~jmunkki              Windsurfing: Faster than the wind.
  2553.  
  2554. +++++++++++++++++++++++++++
  2555.  
  2556. >From mwhid@native.cis.ufl.edu (Michael C. Whidden)
  2557. Date: 7 Dec 1995 14:54:36 GMT
  2558. Organization: Univ. of Florida CIS Dept.
  2559.  
  2560. >However, when I was testing the frame rate, I noticed a weird thing.  If I had 
  2561. >extensions turned off, the frame rate was around 360 frames/sec.  If I turned 
  2562. >extensions on, the frame rate was about 270 frames/sec.  (You're probably 
  2563.  
  2564. >So I'm wondering, are there certain kinds of background processes that can 
  2565. >occur whether or not I'm calling WaitNextEvent?  (I'm sure the After Dark 
  2566. >thing is not a RAM issue, the System and the game each take up about 5 megs on 
  2567. Yes.  Interrupt handling routines execute and there's nothing (realistically)
  2568. you can do about it.  Interrupt routines do things like redraw the screen,
  2569. listen to your modem, play your sounds, etc...  My guess is that AfterDark
  2570. is installing a routine that executes at regular, timed intervals for the
  2571. purposes of figuring out how long it has been since you last moved the
  2572. mouse or pressed a key.  (so that it can turn on after 15 minutes of
  2573. idle time or whatnot.)  Not much you can do about it.
  2574.  
  2575. -Mike
  2576.  
  2577.  
  2578. -- 
  2579.     /\   /|                                  |  mwhid@cis.ufl.edu
  2580.     | \ | |      \                           |  cirop34@grove.circa.ufl.edu
  2581.    /  | | |  @   |  /                        |  hubris@ufcc.ufl.edu
  2582.   /    \| |  \   |/      ___                 |And don't miss all the great  
  2583.  
  2584. +++++++++++++++++++++++++++
  2585.  
  2586. >From donarb@wolfenet.com (Don Arbow)
  2587. Date: Thu, 07 Dec 1995 13:50:25 -0700
  2588. Organization: Wolfe Internet Access, L.L.C.
  2589.  
  2590. In article <4a4vjo$cbl@eccdb1.pms.ford.com>,
  2591. dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way) wrote:
  2592.  
  2593. :  Juri Munkki (jmunkki@gamma.hut.fi) wrote:
  2594. :  > In article <49ufan$kgj@newsy.ifm.liu.se> ingemar@lysator.liu.se (Ingemar
  2595. :  Ragnemalm) writes:
  2596. :  > >It makes a big difference if you use WNE with a sleep time > 0, or have
  2597. :  > >lots of applications in the background.
  2598. :  >
  2599. :  > During games, I never call WNE. I may call GetNextEvent, if the user
  2600. :  > has background processing enabled, but the best thing is usually to
  2601. :  > call only GetOSEvent, since it doesn't allow any background processing.
  2602. :  
  2603. :  (I wanted to start a new thread on this, since I had some questions about
  2604. :  WaitNextEvent.)
  2605. :  
  2606. :  I'm writing a game in which I'm NOT calling WaitNextEvent (or anything 
  2607. :  similar) unless the user decides to enable "background processing" in a 
  2608. :  preferences dialog.  My initial impression was that if I didn't call 
  2609. :  WaitNextEvent, I wouldn't have to worry about background processes taking up 
  2610. :  valuable CPU time.
  2611. :  
  2612. :  However, when I was testing the frame rate, I noticed a weird thing. 
  2613. If I had 
  2614. :  extensions turned off, the frame rate was around 360 frames/sec.  If I
  2615. turned 
  2616. :  extensions on, the frame rate was about 270 frames/sec.  (You're probably 
  2617. :  thinking that's damn fast anyway, but this is on a 7200/90 and I still
  2618. have to 
  2619. :  add a lot more complexity to the game.)  It turned out that the main culprit 
  2620. :  was AfterDark (2.0).  If I removed AfterDark, the frame rate was about the 
  2621. :  same whether other extensions were on or off.
  2622. :  
  2623.  
  2624. One of the problems with calling WNE, is that it is not native.  It is
  2625. still 68k code,
  2626. so each time you call it on the PowerPC, it requires a Mixed Mode switch. 
  2627. Every Mixed
  2628. Mode switch requires the execution of approximately 500 PowerPC instructions.
  2629.  
  2630. An interesting experiment as shown in the book "Programming the PowerPC" shows
  2631. a simple program that draws some output on the screen.  It loops 10,000 times.
  2632. The first version of the program ran in 8 seconds.  By adding a call to
  2633. WNE to allow the
  2634. user to jump out of the loop by pressing a key, execution time was
  2635. increased to 30 seconds,
  2636. because of the overhead of Mixed Mode calls.
  2637.  
  2638. If you're calling WNE on a PowerPC, make sure you don't call it every time
  2639. through
  2640. your event loop.  Mixed mode thrashing causes a lot of slowdowns with
  2641. WNE.  I use
  2642. a timing variable that only calls WNE every 15 ticks when running on a PowerPC.
  2643. That will effectively speed up your event loop. 
  2644.  
  2645. Don
  2646.  
  2647. -- 
  2648. - ------------------------------------------------------------------------
  2649.     \ | /    Don Arbow, Partner      |  donarb@wolfenet.com
  2650.   -- EDO --  EveryDay Objects, Inc.  |  http://www.pla-net.net/edo
  2651.     / | \    Seattle, WA             |
  2652. - ------------------------------------------------------------------------
  2653.   My Prographing web page:   http://www.wolfe.net/~donarb/Dataflow.html
  2654.         "The fix is only temporary, unless it works" - Red Green
  2655. - ------------------------------------------------------------------------
  2656.  
  2657. +++++++++++++++++++++++++++
  2658.  
  2659. >From tt@muc.de (Thomas Tempelmann)
  2660. Date: Fri, 08 Dec 1995 12:46:51 +0100
  2661. Organization: MUC.DE e.v -- private Internet access
  2662.  
  2663. In article <4a4vjo$cbl@eccdb1.pms.ford.com>,
  2664. dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way) wrote:
  2665.  
  2666. >I'm writing a game in which I'm NOT calling WaitNextEvent (or anything 
  2667. >similar) unless the user decides to enable "background processing" in a 
  2668. >preferences dialog.
  2669.  
  2670. I do that in my games (from Dongleware, e.g. OXYD, Tubular Worlds), too.
  2671. It seems to work good.
  2672. But if you do not call WNE but GetOSEvent, you should also call SystemTask
  2673. around every 1/60 second (at most) in order to allow drivers to get some
  2674. time if they require it. It makes it a little bit more compatible and will
  2675. not consume much time, since the drivers are asked no to perform
  2676. time-consuming tasks here.
  2677. At least, I had the impression that PowerBooks need that SystemTask call
  2678. (which is performed implecitly when you use WNE) in order to control HD
  2679. spin down and similar tasks.
  2680. Although I'm not 100% sure about this, it is just a good idea to call
  2681. SystemTask anyway.
  2682.  
  2683. Thomas
  2684.  
  2685. - -
  2686. Thomas Tempelmann, Tuerkenstr. 31, D-80799 Muenchen, Germany.
  2687. E-mail: tt@muc.de (private), tempel@eWorld.com (business)
  2688. Phone: (++49) (89) 286590-90, Fax -89
  2689.  
  2690. +++++++++++++++++++++++++++
  2691.  
  2692. >From hnsngr@sirius.com (Ron Hunsinger)
  2693. Date: Fri, 08 Dec 1995 07:01:06 -0800
  2694. Organization: ErsteSoft
  2695.  
  2696. In article <4a4vjo$cbl@eccdb1.pms.ford.com>,
  2697. dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way) wrote:
  2698.  
  2699. > I'm writing a game in which I'm NOT calling WaitNextEvent (or anything 
  2700. > similar) unless the user decides to enable "background processing" in a 
  2701. > preferences dialog.  My initial impression was that if I didn't call 
  2702. > WaitNextEvent, I wouldn't have to worry about background processes taking up 
  2703. > valuable CPU time.
  2704. > However, when I was testing the frame rate, I noticed a weird thing.  If
  2705. I had 
  2706. > extensions turned off, the frame rate was around 360 frames/sec.  If I turned 
  2707. > extensions on, the frame rate was about 270 frames/sec.  (You're probably 
  2708. > thinking that's damn fast anyway, but this is on a 7200/90 and I still
  2709. have to 
  2710. > add a lot more complexity to the game.)  It turned out that the main culprit 
  2711. > was AfterDark (2.0).  If I removed AfterDark, the frame rate was about the 
  2712. > same whether other extensions were on or off.
  2713.  
  2714. The problem here is that AfterDark patches a lot of system traps. In
  2715. version 2.0, the patches are all 68K code, so that if native code calls
  2716. one of the patched traps, you have two mode switches: one from native mode
  2717. to emulator mode, and then another one just a few instructions later to go
  2718. back to native mode. These mode switches are very expensive.
  2719.  
  2720. Version 3.0 of AfterDark makes fat patches, so you won't have this
  2721. slowdown if you upgrade.
  2722.  
  2723. > So I'm wondering, are there certain kinds of background processes that can 
  2724. > occur whether or not I'm calling WaitNextEvent?
  2725.  
  2726. As other people have told you, interrupt routines still run even if you
  2727. don't call WNE.
  2728.  
  2729. I applaud your decision to make it a user preference whether to give time
  2730. to background tasks. Just because I'm playing a game doesn't mean I don't
  2731. have anything else going on. I usually want to let background tasks get
  2732. their time, and if they take too much I'll either quit them or (if the
  2733. game allows) starve them. I don't want the game to make that decision for
  2734. me. A game that takes over the whole machine is a game that I cannot
  2735. always afford to run.
  2736.  
  2737. You can can use the event manager and still starve background tasks if you
  2738. want by calling GetOSEvent instead of WaitNextEvent or GetNextEvent. But:
  2739.  
  2740. If you starve background tasks, they can't update their windows. This may
  2741. look ugly. Even if your game (impolitely) takes over the whole screen, the
  2742. user may have other screens with windows on them.
  2743.  
  2744. Some screen savers won't work if background tasks don't get time. Yes, I
  2745. know your game is wonderful, but my phone still rings, people still come
  2746. to the door, and sometime I have to leave the game unattended for a while.
  2747.  
  2748. > (Also, I'm curious as to why Juri calls GetNextEvent rather than 
  2749. > WaitNextEvent.  Is it more efficient?)
  2750.  
  2751. WaitNextEvent calls GetNextEvent. WaitNextEvent with a sleep time of zero
  2752. is the same as SystemTask;GetNextEvent. Unless you have desk accessories
  2753. running in your heap (extremely unlikely), SystemTask doesn't do anything,
  2754. so in this case WNE and GNE are equivalent.
  2755.  
  2756. (Actually, as I write this, I suddenly find myself unsure. Is it
  2757. SystemTask or GetNextEvent that gives time to background processes? I know
  2758. they hang on a GNE waiting for the time, and get it with a nullEvt, but
  2759. that doesn't of itself demand that the front process give up the time with
  2760. GNE.)
  2761.  
  2762. The advantage of WNE over GNE comes when the sleep time is greater than
  2763. zero. In this case, WNE is more efficient about giving time to background
  2764. tasks, because it knows how much it can starve the foreground task. But
  2765. then, you probably aren't actively seeking ways to starve your action-type
  2766. game.
  2767.  
  2768. -Ron Hunsinger
  2769.  
  2770. +++++++++++++++++++++++++++
  2771.  
  2772. >From reed@medicine.wustl.edu (Thomas Reed)
  2773. Date: Mon, 11 Dec 1995 09:23:06 -0600
  2774. Organization: Washington University
  2775.  
  2776. In article <4a4vjo$cbl@eccdb1.pms.ford.com>,
  2777. dway@PROBLEM_WITH_INEWS_GATEWAY_FILE (Douglas E. Way) wrote:
  2778.  
  2779. >(Also, I'm curious as to why Juri calls GetNextEvent rather than 
  2780. >WaitNextEvent.  Is it more efficient?)
  2781.  
  2782. WaitNextEvent basically calls GetNextEvent and SystemTask.  By calling
  2783. GetNextEvent, you get that portion without the automatic allocation of
  2784. time to the system.  Of course, you could do the same thing with the right
  2785. sleep value passed to WaitNextEvent...
  2786.  
  2787. -Thomas
  2788.  
  2789. =====================================================
  2790. Thomas Reed                     Washington University
  2791. reed@visar.wustl.edu               Medical School
  2792. reed@medicine.wustl.edu            Saint Louis, MO
  2793. http://medinfo.wustl.edu/~reed
  2794. - ---------------------------------------------------
  2795. Clothes make the man.  Naked people have little or no
  2796. influence on society.  -- Mark Twain
  2797. =====================================================
  2798.  
  2799. Opinions posted are not the opinions of Wash. U.
  2800.  
  2801. ---------------------------
  2802.  
  2803. End of C.S.M.P. Digest
  2804. **********************
  2805.